Skip to content
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

Open
guybedford opened this issue Jun 24, 2018 · 3 comments
Open

Supporting CommonJS subpaths #20

guybedford opened this issue Jun 24, 2018 · 3 comments

Comments

@guybedford
Copy link
Contributor

guybedford commented Jun 24, 2018

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.

@guybedford
Copy link
Contributor Author

guybedford commented Jun 24, 2018

Some common examples:

  • import 'react-dom/server'
  • import '@angular/common/http'

@zenparsing
Copy link
Owner

I agree that this will be considered a big weakness of the proposal.

  • @angular/common/http is already a directory, so our current semantics would work fine for that case.
  • react-dom/server is problematic. That repository would have to be updated in order to support import "react-dom/server" natively.

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 src directory that usually just "re-export" some module inside of src.

Maybe we can use this as an opportunity to better support deep-package paths?

More on this later...

@guybedford
Copy link
Contributor Author

Maybe we can use this as an opportunity to better support deep-package paths?

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants