New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Breaking: define an exports
field for our public API
#13654
Comments
When adding this, you can use Either way, I'd be happy to review any change around this field for correctness (node 13.0 and 13.1, if supported, require extra consideration in the format, as do a few non-latest minors in 12 and 14); please feel free to ping me. |
@kaicataldo Did you mean to link to here? This seems like a simple enough change to prevent any further misunderstandings about what is and isn’t a public API. |
That's right - looks like the docs were moved. |
Note as well that all my complaints about breaking changes in non-majors from renaming internal files would go away if internal things were excluded from "exports" :-) (or at least, change to feature requests to expose them explicitly) |
TSC Summary: This proposal seeks to add an TSC Question: Shall we accept this proposal and add it to the public roadmap (for v8.0.0). |
In the 2020-10-08 TSC meeting, we accepted this as a semver-major change for the v8.0.0 release. I've added it to our public roadmap. The next step is for someone to write an RFC outlining which endpoints we need to expose and hopefully identifying which packages currently import private API that will be affected by this change. As we start working on v8.0.0, we can mention this change in a blog post to give those packages plenty of notice. |
@btmills once the choices are made, I’d be happy to volunteer to write the PR to implement it. |
We’d like to include this in our upcoming v8.0.0 release if possible. The next step is to write an RFC specifying which portions of our API we want to expose via |
Once the list of entrypoints exists, i will still happily make the PR to define them. |
worth noting that @typescript-eslint does a bunch of deep, direct importing of rules so that we can define extension rules. Which I'd assume this change would break? We could technically go via the root import - but I thought it was nicer to restrict the footprint of the import. Probably makes no difference though as ESLint should have already been |
* New: Add ESLint#getRulesMetaForResults() (refs #13654) * Update docs * Update docs/developer-guide/nodejs-api.md Co-authored-by: Brandon Mills <btmills@users.noreply.github.com> Co-authored-by: Brandon Mills <btmills@users.noreply.github.com>
note - this should not have been closed yet - the PR only adds one piece of it. |
Thanks for catching this @bradzacher, looks like automation got excited. Reopening and re-adding to project boards. |
* Breaking: Strict package exports (refs #13654) * Update docs * Fix linting errors * Update docs/developer-guide/nodejs-api.md Co-authored-by: Milos Djermanovic <milos.djermanovic@gmail.com> * Update docs/developer-guide/nodejs-api.md Co-authored-by: Milos Djermanovic <milos.djermanovic@gmail.com> Co-authored-by: Milos Djermanovic <milos.djermanovic@gmail.com>
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!
The text was updated successfully, but these errors were encountered: