-
Notifications
You must be signed in to change notification settings - Fork 5
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
Supporting CommonJS subpaths #20
Comments
Some common examples:
|
I agree that this will be considered a big weakness of the proposal.
I have used "deep-linking" myself on packages where I want to separate out non-essential features from the main package. But the mechanism that we're using to accomplish it right now is pretty awkward: I have one or more script files that are outside of the Maybe we can use this as an opportunity to better support deep-package paths? More on this later... |
In principle I like that deep paths could be disabled in the ESM loader for a more well-defined manifest, and then somehow legacy supported only like this spec does for "index.js", but I'm not sure it quite works out this nicely. Whatever is done here - disabling deep package paths would either need to be opt-in, or gets back to the problem of needing to defining an "esm package". What is so nice about this spec is it doesn't worry about "esm package" but rather simply working out "a package that is definitely not esm". This is why that is the switch that I have proposed above here. |
This is kind of the main drawback of this proposal, and I'm just wondering if there might not be a way to handle it.
Currently the switch is treated as "if there is no 'module' or 'default.js' and there is a "main" or index.js then load the 'main' or 'index.js' as CommonJS"
What if we extended the switch to subpaths: "if there is no 'module' or 'default.js' and there is a 'main' or 'index.js', then treat subpath requires as CommonJS".
This still retains the value of this proposal in not imposing a flag on users, while still supporting the expected workflows.
The text was updated successfully, but these errors were encountered: