Breaking: Strict package exports (refs #13654)

[nzakas]

Prerequisites checklist

• I have read the contributing guidelines.

What is the purpose of this pull request? (put an "X" next to an item)

[ ] Documentation update
[ ] Bug fix (template)
[ ] New rule (template)
[ ] Changes an existing rule (template)
[ ] Add autofixing to a rule
[ ] Add a CLI option
[x] Add something to the core
[ ] Other, please explain:

What changes did you make? (Give an overview)

This implements the strict package exports RFC by updating api.js and implementing unsupported-api.js.

This does not implement ESLint#getRulesMetaForReport() method. I'll do a separate PR for that piece.

Is there anything you'd like reviewers to focus on?

Please check that this matches the RFC. Also, how do we want to document the use-at-your-own-risk entrypoint? Should that be on the Node.js API page, or should we just omit it and trust that people who want it will find it?

[nzakas]

Hmmm, there's a ton of linting errors on the master branch right now.

[btmills]

I'm not able to repro any failures on master locally, and the last commit to master passed checks: https://github.com/eslint/eslint/runs/2809970160. Your first commit changed a bunch of rule tests, which I wasn't expecting. Were those changes intentional?

[mdjermanovic]

You probably have an old version of eslint-plugin-eslint-plugin locally installed.

[nzakas]

Ah ok, weird. I definitely didn’t intend to change all of those files it must have happened when I ran auto fix. I’ll try updating the plugin

[nzakas]

Thanks @mdjermanovic that did the trick!

[nzakas]

Forgot to mention: the more I think about it, the more I feel like the use-at-your-own-risk entrypoint should not be documented. People were already digging around the eslint package and finding APIs to use that weren't documented before. I don't want to implicitly "bless" stuff in use-at-your-own-risk by documenting it, but would like to hear other thoughts.

[ljharb]

By documented, you mean in prose? as long as it's in package.json "exports" that seems fine.

[nzakas]

@ljharb yes, in prose. Forgot people could just look in package.json 🤦

[mdjermanovic]

Forgot to mention: the more I think about it, the more I feel like the use-at-your-own-risk entrypoint should not be documented. People were already digging around the eslint package and finding APIs to use that weren't documented before. I don't want to implicitly "bless" stuff in use-at-your-own-risk by documenting it, but would like to hear other thoughts.

I agree that we shouldn't document the use-at-your-own-risk entrypoint, as we don't want to encourage its use.

btw it seems that exports in package.json doesn't restrict require(<absolute path>), so all internal modules still can be loaded from other packages, like this:

const accessorPairs = require(
  path.resolve(path.dirname(require.resolve("eslint")), "rules", "accessor-pairs")
);

[mdjermanovic]

LGTM aside from two small documentation suggestions I left.

[nzakas]

Thanks for catching those docs issues.