[Do not merge] doc: Add pkg-exports proposal to resolve spec

[jkrems]

A potential way of expressing https://github.com/jkrems/proposal-pkg-exports in terms of the resolver spec.

[guybedford]

As mentioned when we discussed, I still worry a little about this in cases where packages do not have a package.json file, as in theory it should still be possible to resolve subpaths in these cases (for eg legacy package backwards compatibility)?

[jkrems]

The case would be:

mkdir -p node_modules && touch node_modules/foo.mjs
esm-node -e 'import "foo.mjs"'

Is this something we should allow via import? It would continue to work for .js and via require for people who truly need it.

[guybedford]

And also where node_modules/pkg/x.js exists without a node_modules/pkg/package.json I think? Or is that ok?

[jkrems]

Any package installed via npm/yarn would have a package.json afaik. Manually created package-less files in node_modules feel like a hack that exploited the previous design space to get a specific result. I don't believe too many people who know node would be able to understand why it's working (or expect to find it in a project).

If we do want to support this for power users, I believe it should be opt-in (e.g. via loader or config), not the default.

[weswigham]

I think having this kind of manual public entrypoint specification probably has value for cjs just as much as esm, tbh. And for cjs, this would need to be opt-in, so it'd make sense for esm to be the same.

[weswigham]

That's well and good, but I'd rather that not be tethered to esm just because it seems like a sneaky way to introduce changes without them obviously being breaks. And like I said and you agreed, this has equal value describing what people want to be able to accomplish with plain ole cjs - which leads me to the conclusion that this aughta be a core cjs loader feature that is replicated in the esm loader, rather than going the other way and trying to "backport" the feature to cjs in the future. Heck, it's an argument for designing explicitly with cjs in mind to ensure it works for it. And as an added bonus, if you propose this for cjs proper, it could start getting worked on being merged into core right away if people agree.

[jkrems]

[...] it seems like a sneaky way to introduce changes without them obviously being breaks.

I think that's an overly negative way of portraying it. It's not about sneaking in changes, it's about being able to clean up the API. CJS has a lot of assumptions built in, e.g. how it's tied to a specific file system layout. I don't think it's realistic to remove those assumptions (or even just loosen them) but maybe I'm wrong.

From observing what people are doing in practice, I assume CJS as implemented in node core will be more and more a system that people just wholesale replace. Yes, landing features in core for CJS might be possible. But then we'd just have to reimplement it each replacement again until node-CJS becomes usable as-is. And I'd be (positively) surprised if node core would be prepared to take on the potential perf regression of a more flexible CJS system that still preserves full compatibility with all existing code.

[weswigham]

And I'd be (positively) surprised if node core would be prepared to take on the potential perf regression of a more flexible CJS system that still preserves full compatibility with all existing code.

Can't you bill this as potentially improving perf by allowing the resolver to skip disk hits for fallback locations when exact mappings are provided?

[jkrems]

This is about the more general thing: Being able to not even hit the disk for resolution and storing packages outside of an on-disk hierarchy in node_modules. That is the reason why people replace the whole CJS system and/or shim around FS (see source of tink or yarn pnp). That implies adding hooks into the resolution pipeline which might affect out-of-the-box performance.

[jkrems]

I'm not saying the end result when using the npm or yarn resolver would be slower. It would be faster. But at the expense of using node without those resolvers. Which is what node core would realistically benchmark. If node core doesn't add those hooks, I'm not sure it's super relevant if it adds exports support because nothing would actually hit that code.

[MylesBorins]

@jkrems I attempted to rebase this again #12 but there is now a conflict. Would you be able to update?

[jkrems]

Rebased or rather did a hard reset followed by cherry-pick. I think this should be back to a valid diff.

[MylesBorins]

@jkrems would you be able to rebase?

[MylesBorins]

removing agenda label for right now, please let me know if we should bring it back

[jkrems]

I think this has been subsumed by some the other work that happened in the meantime. Closing for now.