exports field for our public API #13654Description
The version of ESLint you are using.
Latest
The problem you want to solve.
Downstream packages rely on ESLint's internal modules, and removing/altering these modules can cause breakages in the ecosystem (example here). A lot of thought has gone into what is and isn't our public API (defined here), but it would be great to be able to enforce that downstream packages don't rely on these modules, since treating every module in our codebase as public isn't practical and would make it extremely difficult to refactor or do feature work.
To be clear, I don't think that our current strategy of defining our public API and then treating all other modules as "private" is an uncommon practice, but I do think this small change could prevent some instances of this from happening in the future.
Your take on the correct solution to problem.
As suggested here, I would like to propose that we define an exports field to a) clearly document what we consider our public API from an importable module standpoint, and b) prevent those using more recent versions of Node.js from importing internal modules not intended for public consumption. For older versions of Node.js, main (which we have defined) would be used as a fallback. You can find more details in the Node.js Package Entry Points docs.
Are you willing to submit a pull request to implement this change?
Absolutely!
Metadata
Metadata
Assignees
Labels
Type
Projects
Status