Supporting CommonJS subpaths

[guybedford]

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]

Some common examples:

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

[zenparsing]

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]

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.