-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
import.meta.filename and import.meta.dirname #50
Comments
I think the desire for Node users at least would be for these two new methods to return the same strings that Node users are familiar with from CommonJS
Note the lack of trailing slash on We also should standardize what For reference:
|
My preference would be for runtimes (and wintercg) to...
|
Personally I think Bun can keep shipping |
The whole reason to add those for Node.js familiarity with |
Deno's stance on this is that we are generally opposed, because it results in different observable behaviour from within a module, depending on if it is served in HTTP (or other remote protocol), or the file system. If the primary use-case is to reference assets relative to a given module, then a developer may use Instead, developers should use Are there other use-cases that do not fall into the above class? |
What if we conditionally expose Als a relevant issue since dealing with platform filesystem paths and File URL requires platform normalization. The Node.js methods |
My concern is primarily one of portability. If a developer relies on This is not just a concern for runtimes like Deno where local development happens on file URLs, and published modules are http URLs, but also for bundlers, and even node with custom loaders. In all of these cases, code may work in one scenario, and break in another. This is a portability hazard -- we should not add more portability hazards, especially in a standards venue explicit created to promote portability. |
I missed that Bun also has |
What I would ask is that if Node.js and Deno want to ship Absent such a spec, these properties should be namespaced, e.g. |
Any code that uses Node also runs code from HTTPS URLs, and from |
I think since Bun has already shipped this and Node intends to (either under |
Filesystem modules and url-fetched modules are fundamentally different; I’m not sure why that portability is expected. |
@ljharb I agree that modules that would (optionally) depend on the filesystem ( But I guess the standpoint of Deno is that with a stricter standard ( I guess my question is that, at this point is "filesystem support" part of common-minimum-api spec? (because if not, i think as was talking in yesterday meeting we might simply delegate it to (scoped) runtime specific implementation rather than standard). There is so more to it. URL is (almost!) a web standard. Filesystem especially considering lovely windows, is not. |
@pi0 developers can’t be forced to do things, and imo shouldn’t. That goal (importing from a URL) kind of works at a package granularity, but not at that of a file/module. CDN-friendliness is an antigoal to me. |
Definitely agree with you @ljharb on that we cannot force developers nor runtimes not to do something and anyway runtimes such as Bun and Node.js would introduce their version of filename/dirname at some point. (I personally also will use dirname/filename meta if available but only for packages that are intended to be used locally not from a CDN like build tools or CLIs). I think the earlier conclusions here were to either let runtimes (and developers) have their version and only encourage to use namespaced meta to make sure different implementations are clearly separated. My counterpoint is, as a "minimum common standard" how much we can well define filename and dirname in a platform-agnostic way especially when many of current runtimes do not even have a definition of or support filesystem. |
Bun is open to compromising here and making
Bun is not in favor of namespaced import.meta properties like We don't have an opinion yet on what to do about modules which don't come from the filesystem. Instinctively, I'd think they would behave like a URL's pathname, excluding search params and the fragment. I think making them |
So I guess we at least agree on
I’m conflicted on this. On the one hand @Jarred-Sumner is absolutely correct, |
I'm with @lucacasonato on this... developers should use
don't really see much use case for having dirname and filename resolve works in browsers. |
They’re not interchangeable, hence the request. |
I agree with @lucacasonato's points. The proposed properties are neither necessary nor portable and, in some ways, a step back. We probably shouldn't encourage their use even if they exist. However, enough folks seem to want these properties for convenience, despite these issues.
On the other hand, explicitly making them undefined would at least force folks who use TypeScript to double-check if they really want to use properties that might not exist. |
Not all code needs to be portable, and forcing that code to be less convenient seems a bit heavy handed. |
My opinion on this has not changed since my last comment. The points I made above still hold true. Pushing for a Also, I'd like to see how proposal authors intend to integrate this into TypeScript types. TypeScript has no mechanism to enable different This seems entirely like we are trying to solve an education problem by introducing a footgun. This seems generally bad. |
I don't see why that's an issue? Presumably if someone loads @types/node that augments
Users have been asking for this for a while and it's a real quality of life feature. There is only so long we can tell our users that the way they want to write their code (with paths in case paths are important) they're wrong and instead we need to enable them to author the software they want. |
oh, i'd also add - i don't necessarily want my code to be portable to an environment i don't expect and support. If you want to use my code in a place I didn't intend, you should have to either fork it or ask me to allow for it, so I can add proper tests - otherwise there's no limit to what users will feel entitled to demand for free from open source maintainers. |
Node can run HTTPS and This would be a good thing, though: having these typed as potentially undefined would provide a hint to users about the portability risk, and push them to write conditional code that can handle either environment. |
Yeah for TS I'd expect |
Presumably the node types for |
When going over "use HTTPS and data urls" use cases and "use import.meta.filename" use cases I suspect the intersection is tiny though? |
I would love to hear from other folks who have a stake in portability and would be impacted by this, namely folks working on bundlers. I concerned that this import.meta property will give users the expectation that bundlers can and do understand cc @patak-dev @lukastaegert @devongovett @sokra (feel free to forward if anyone else is more interested in answering)
Except it is not always present in Node, as previously explained. So it can not be typed as "unconditional string" in Node either.
This is totally besides the point? I don't care about the intersection use case - I would if I wanted |
Working on |
I have no problem with supporting additional import.meta properties in Parcel. We already compile For portability concerns, maybe |
This comment was marked as off-topic.
This comment was marked as off-topic.
This have been handled by creating the |
One of the most annoying things in the ESM implementation in Node.js is the lack of
__filename
and__dirname
to work with paths from ESM files.I would recommend we specify
import.meta.dirname
andimport.meta.filename
as optional shared metadata, returning the local paths in the filesystem as strings (and notfile:https://
URLs).For more context: nodejs/node#48740
The text was updated successfully, but these errors were encountered: