-
Notifications
You must be signed in to change notification settings - Fork 43
Unflagging self reference specifiers #403
Comments
If there’s an opt-in, then perhaps the user can determine their own sigil? ie:
could enable the package name (and require one to be present in package.json), and:
would enable use of the tilde, etc. Perhaps that compromise would allow everyone to get the sigil they want without needing to bless one, or to be able to use the package name - and being opt-in, it would be able to ignore node_modules entirely. We could also support a more complex form if people wanted both the name and a sigil (but that seems like too much to me to go in the first unflagged iteration). |
at that point, why not |
Thanks @jkrems for your ongoing work on this feature, it is really really appreciated. I know having a PR open for a long period of time can be incredibly demotivating, but this would provide some really great usability features for packages. I have concerns about this feature applying after a For example, say you have pkg@1.0.0 and pkg@2.0.0 in the same app, where one of them is aliased. if we go with the package.json "name" and you could have a folder structure like:
inside of This seems risky to me in that we no longer have the guaranteed semantics of this feature for package authors, and possible hidden bugs. If the reason for not supporting this is CommonJS backwards compatibility, perhaps we can do a CIGTM run with the node_modules lookup removed and see how it fares? I suspect every use of Then based on that feedback we could decide what to do further. |
I don't think so..? In your example, each |
Gotcha for my comment: If the nested |
I've updated the example to instead use a base-level alias. If we are arguing that this is rare enough not to be an issue, then surely it is rare enough not to be an issue on the backwards compatibility path? It would just be useful to run the smoke tests and see how this fares to see if we can go this route. |
I think it's a difference between new users and existing users. An existing user is allowed to depend on the existing behavior, however rare their use case or solution may be. A new user is expected to accept the restrictions of the new feature, especially if their use case or solution is unusual or rare. |
I assume it probably wasn’t meant to be serious, but oh how I would love it if we actually shipped 📦 as the sigil. Would such a thing be a first in a programming language or runtime? I don’t think the sigil should be configurable. We just need to make a decision, even if it takes votes. And we can ship the “name” version now and add the sigil later. |
One thing worth noting: I personally think discouraging the use of this feature outside of tests and examples is good™. So I don't believe that breaking advanced package layouts is a showstopper. It depends on what we say about the use cases we aim to support. |
It was serious. I think it's a good way to cut through the very subjective arguments for the various ASCII characters, all of which are terribly overloaded by decades of use in programming languages and computer systems. |
@GeoffreyBooth why don't you think the sigil should be configurable? |
I'm +1 on not making it configurable. It would mean that not only would people have to learn about this kind of resolution, they would have to check for every single directory/project what the syntax is and may get confused every once in a while encountering yet another opinion on the proper sigil. |
Because configurability of this feature adds no value to users. It’s just punting a decision to users that we can make ourselves.
For that matter, we could also have 🏠 to mean |
The most common solution for this already is to use a babel transform, that is already configurable and might vary per project, or even per directory - I'm not sure the confusion is really a big problem in practice. @GeoffreyBooth that's the problem - we haven't been able to make the decision ourselves. |
If everyone involved agreed on a single sigil, whatever it was, and there was no dispute and the decision was unanimous; then if someone proposed, hey, let’s make this configurable, I think the response would be, “why?” It just doesn’t add value to users, and it adds cost: one more thing to learn, one more thing in the docs, one more thing to maintain and test, one more thing to be aware of by both users and tools, etc. Configurability shouldn’t be a crutch to avoid making decisions. |
To be fair, the unconfigurable variant is also one more thing to learn, one more thing in the docs, one more thing to maintain and test, one more thing to be aware of by both users and tools, etc. |
Right, it's one more thing to learn. But not |
Well if you consider node's resolution system the one true resolution system, then sure it's one. But if you include all the other things that can support esm, you're back to |
If you adjust one number, then please also write down the other. If we include all the other things and assume that there are I think realistically the number of tools is closer to a constant when compared to the total number of packages and apps. In which case we're absolutely not up to |
@jkrems i'm arguing that this feature shouldn't exist, not that it should be configurable :) |
@devsnek Which feature? Or rather: which use case do you think shouldn't be supported? |
@jkrems specifically: self-reference specifiers. Generally: anything strengthening the idea of package boundaries. |
@devsnek That's not the question I asked though. I asked which of the use cases you would like or wouldn't like to see supported. The question I asked was specifically aimed at looking at alternatives. Nothing I asked implied that it would be based on package boundaries. |
@jkrems i'd like to see all the use cases be addressed somehow. My concerns lie more with the specific solutions currently suggested for certain use cases. I don't always have a better solution on-hand, but sometimes it is better to take more time on a problem than to push out the first solution we come to. |
Do you think any of these use cases need additional support for shipping modules? Or do you think some or all of them could be addressed independently? |
I think we've already gone above and beyond (maybe even too far beyond) what is needed for stable modules. Back on topic: iirc there were some quiet discussions about import maps supporting this case as well. I think it might be valuable for us to engage a bit more with import maps, and maybe also with yarn/npm/etc, as they are in a prime position to generate import maps. |
Side note: This can easily be read as dismissive of other people's work. I hope you are aware that this is not the first solution we came up with. It's the result of many months of iteration, with various solutions being considered by multiple people. I assume that's not what you meant but to me it sounded a bit dismissive of the effort that went into the current proposal. |
It's worth noting we do have a design for a more configurable version of this feature via package imports. See https://github.com/jkrems/proposal-pkg-exports#3-imports-field. That allows a configurable way of setting this specifier as well. |
Fixed by nodejs/node#31002? |
Background
Open Questions
Use Cases
We know of a handful of use cases:
exports
.All of these can be solved today, to a certain degree, using symlinks, special scripts, or features like loaders/require extensions. But there's no first-class support for them in node.
We need to decide which use cases are in scope and which aren't. Specifically: which use cases are in scope for shipping modules themselves. A use case not being in scope doesn't mean we should prevent it.
Outcome
Shorter Syntactic Sugar
Some people have called for a shorter syntax to be used either in addition or instead of the package name. Most suggestions so far have been ASCII characters but each choice has come with concerns about existing uses:
~
: Used in the ecosystem for a different feature (require internal project files from a static root, not relative to the package scope). But that feature is close enough that it could count as ecosystem precedent. May be confused with posix expansion of home directories when an unquoted~
is used in shells.@
: Used in the ecosystem for a different feature (npm scopes). But that feature is close enough that it could count as ecosystem precedent. Also used in some languages (e.g. CoffeeScript, ruby) as a reference to "this" or "self".%
: Used in (URL) specifiers already for percentage encoding. Used in Windows for variable substitutions (%HOME%
). Sometimes associated with "placeholder".^
: Used in regular expressions and other places as "start" or "beginning". Can also refer to the control key.Beyond ASCII, we could also use other characters since JS sources are usually UTF8:
Outcome
Opting In
This applies mostly to a world with syntactic sugar.
There are two downsides of sugar that may make opt-ins for them necessary:
Outcome
Resolution Order
In short: Should it apply before or after looking at
node_modules
. The safer choice is likely "afternode_modules
" but with opt-in it may also be possible to do it before.Outcome
node_modules
?node_modules
?node_modules
?The text was updated successfully, but these errors were encountered: