Option to skip validation for Node10

[Sebastian Lorenz]

Hi. Is there an option to entirely skip validation for Node10? It's possible to run it with --ignore-rules no-resolution but unless I'm wrong that also skips that rule for the other categories, correct?

[Andrew Branch]

This is more or less something I have been wanting/planning for some time, but I think I want to implement it differently from --ignore-rules. I think the results for every resolution option should always be visible, but you should be able to control the criteria for a passing/failing exit code. In addition to some kind of granular config, I was imagining that this could open up some kinds of presets/profiles, so a project could say “show me all the results, enforcing that I comply with the esm-only profile.” I can see different projects wanting to validate against at least these profiles:

• strict / max-compat (all rules, all entrypoints, all resolution modes, like today)
• modern (ignore node10)
• esm-only (ignore node10 and node16-cjs)

On the CLI, you could specify what you intend to conform to, whereas on the web, it could show all profiles and whether they’re satisfied. (I know most people using this project only want to test their own code with the CLI, but I personally track trends in the results on several thousand popular packages over time, and it would be cool for me to be able to have an additional useful way to segment that data.)

[Mark Erikson]

Yes, that would be wonderful!

Here's another slightly different scenario to toss out there.

For React-Redux, we've got a couple alternate entry points. React-Redux v8 had "react-redux/next", v9 will have "react-redux/compat". v9 is where we're adding package.exports.

I'm generating the right bundles and setup for package.exports to work, but that /compat entry point won't work under Node10 because I'm not writing a named file to disk in that location. That's intentional. But, that means I've had to disable the check entirely with --ignore-rules no-resolution. It'd be nice if I could just do it for the one entry point or something.

[Ben McCann]

It would be nice if it looked at the engines field in package.json. My package specifies that it only supports Node 16+ via the engines field, so it makes sense to just skip the Node 10 resolution in that case

Similarly, it would be nice to be able to skip the "node16 (from CJS)" validations since my package is ESM-only. I set "type": "module" and use the default condition to provide only ESM code (note that I use default in favor of import because the Node.js error messages are far more helpful if someone incorrectly tries to require the package).

[Ari Becker]

Just to provide another data point - we have both a design library, a web frontend, and an Electron-based app. Until Electron fully supports ESM, it's stuck on moduleResolution: node, and the web frontend uses moduleResolution: bundler. I'd love to add ATTW to CI, but I'd like to skip validation for node16 and only verify that it works with node and bundler, since those are the only module resolution types we use.

[Milan Kovacic]

My package specifies that it only supports Node 16+ via the engines field, so it makes sense to just skip the Node 10 resolution in that case

It is possible for consumers to have typescript moduleResolution set to node10 — regardless of the Node version, in which case the types will be broken.

EDIT: Nvm, didn't read that package is ESM-only :D

[Jake Boone]

Has there been any development on this? @markerikson I'm having the same issue as you mentioned here: #112 (comment). I have some endpoints in package.json that won't (and shouldn't) resolve when npm pack'd. I want to use --ignore-rules no-resolution but only for specific endpoints.

Edit: FWIW, I ended up using --exclude-entrypoints to ignore certain exports altogether.