package.json exports violations aren't caught

[JeremyLoy]

since Node 12, it is possible to define a restricted set of exports which allow encapsulation of modules in a package. It should be an error if an import of any module not in the set of exports is attempted. Otherwise, the error will not be caught until runtime.

import/no-internal-modules and import/no-restricted-paths are not sufficient solutions for this issue, as they require manual upkeep

I made a sample repository demonstrating the issue. It should be pretty simple to checkout and run

[ljharb]

This is known; we don’t support exports yet, because resolve doesn’t support it yet.

When it is supported there, we will support it here.

It’s a best practice anyways to have exports mirror the filesystem for back compatibility, and doing that makes everything work with this plugin, fwiw.

Duplicate of #2525. Duplicate of #2132.

[JeremyLoy]

@ljharb thanks for the quick response, however I disagree about this being a duplicate, and kindly request that this is reopened.

#2132 is about missing main causing an issue. exports can be defined alongside main.

#2525 barely has any content, but even then its talking about unused code causing an issue.

My issue and example project is about attempting to use code that is disallowed by the runtime.

anyways to have exports mirror the filesystem for back compatibility, and doing that makes everything work with this plugin, fwiw.

Again, nothing about having the exports mirroring the filesystem or not. Its about encapsulating modules inside of a package

[ljharb]

You're right that it's not an exact duplicate, but they all have the same root cause - exports is not yet supported.

I'm quite familiar with the purpose of exports - i was on the node modules working group that designed it - but you can achieve encapsulation and back compat if your exports paths also exist on the filesystem.

[JeremyLoy]

Sorry, I'm still missing what mirroring exports paths and the filesystem has to do with this, can you please explain?

It’s a best practice anyways to have exports mirror the filesystem for back compatibility,

backwards compatibility isn't a concern for me at the moment, but I'll pocket this for later, thank you!

and doing that makes everything work with this plugin, fwiw.

This part specifically I'm confused about.

In my sample project I'm exporting "./index.mjs" as ".", but my concern has nothing to do with index.mjs. I want importing the neighboring module to be an error. I don't want it in exports at all.

Thanks for your time

[ljharb]

Sorry if I’ve been unclear. I’m not saying to add unwanted entries to exports - I’m saying to make sure that wanted entries have a LHS that matches the RHS.

Regardless, until we support exports, we can’t warn on importing things that exports should be restricting.