-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
feat: add package.json exports for public packages #6458
Conversation
Thanks for the PR, @bradzacher! typescript-eslint is a 100% community driven project, and we are incredibly grateful that you are contributing to that community. The core maintainers work on this in their personal time, so please understand that it may not be possible for them to review your work immediately. Thanks again! 🙏 Please, if you or your company is finding typescript-eslint valuable, help us sustain the project by sponsoring it transparently on https://opencollective.com/typescript-eslint. |
31984c0
to
6c7b452
Compare
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## v6 #6458 +/- ##
=======================================
Coverage 87.05% 87.06%
=======================================
Files 365 365
Lines 12580 12579 -1
Branches 3720 3720
=======================================
Hits 10952 10952
Misses 1278 1278
+ Partials 350 349 -1
Flags with carried forward coverage won't be shown. Click here to find out more.
|
Hmm.. I can't reproduce the typecheck failure locally... There's no reason it shouldn't work considering it's not the ESM version of the package. Maybe there's an issue with the CI getting the wrong version? Idk why it would be different to local considering it's covered by the yarn.lock |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Glorious, I love it. 👏
Left some suggestions inline but they're all nice-to-haves IMO.
packages/ast-spec/tests/util/parsers/typescript-estree-import.ts
Outdated
Show resolved
Hide resolved
"license": "MIT", | ||
"author": "Josh Goldberg <npm@joshuakgoldberg.com>", | ||
- "type": "module", | ||
+ "type": "commonjs", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should be fixed in JoshuaKGoldberg/ts-api-utils#37 -> ts-api-utils@0.0.22
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess the issue now is that TS won't let us import this file because it sees type: 'module'
and our project is type: 'commonjs'
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could switch to type: 'module'
😈
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup - we can't import the package without this patch.
TS looks at type: module
and treats it as an exclusively esm package, erroring:
src/convert-comments.ts:1:24 - error TS1479: The current file is a CommonJS module whose imports will produce 'require' calls; however, the referenced file is an ECMAScript module and cannot be imported with 'require'. Consider writing a dynamic 'import("ts-api-utils")' call instead.
To convert this file to an ECMAScript module, change its file extension to '.mts' or create a local package.json file with `{ "type": "module" }`.
1 import * as tools from 'ts-api-utils';
~~~~~~~~~~~~~~
So we'll need to keep this patch (in perpetuity?)
Maybe this needs to be changed in the package so it doesn't list type
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I suppose we could take an issue in ts-api-utils. But I do wonder what the actual blockers to typescript-eslint going ESM are.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do wonder what the actual blockers to typescript-eslint going ESM are.
In order for CJS to load ESM, it must use an import()
expression.
ESLlint is CJS and does not use import()
to load plugins - it uses require
(via createRequire
[1])
https://github.com/eslint/eslintrc/blob/main/lib/config-array-factory.js#L1086
https://github.com/eslint/eslintrc/blob/main/lib/config-array-factory.js#L984
So we need to export a CJS API from our packages. Now we could get around that and use ESM with a CJS facade in front of an ESM package and leverage import()
expressions to load the ESM "backend", however our plugin and parser need to have fully synchronous APIs to adhere to the ESLint requirements.
Because the plugin needs to be CJS, all our lint utilities (utils
, type-utils
, scope-manager
, etc) need to be CJS.
Because the parser needs to be CJS, all our parser utilities (visitor-keys
, typescript-estree
, etc) need to be CJS.
So for now we're firmly stuck as a project shipping CJS :(
0aa6a6e
to
a635863
Compare
3da9ffd
to
00af53f
Compare
BREAKING CHANGE:
Restricts API surface by strictly defining package.json exports for each package
PR Checklist
Overview
Configures option 3 from #6050 - where we completely lock down our API so people cannot access our
dist
folder any more.Currently blocked on JoshuaKGoldberg/ts-api-utils#54