-
-
Notifications
You must be signed in to change notification settings - Fork 196
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: provide ESM export (refs eslint/rfcs#72) #469
Conversation
the tests are breaking because |
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.
Looks good! Just a few comments. Also, the reference to Makefile.js
is here:
https://github.com/eslint/espree/blob/master/.github/workflows/ci.yml#L22
Hi @mreinstein!, thanks for the Pull Request The pull request title isn't properly formatted. We ask that you update the message to match this format, as we use it to generate changelogs and automate releases.
Read more about contributing to ESLint here |
Hi @mreinstein!, thanks for the Pull Request The pull request title isn't properly formatted. We ask that you update the message to match this format, as we use it to generate changelogs and automate releases.
Read more about contributing to ESLint here |
This comment has been minimized.
This comment has been minimized.
Hi @mreinstein!, thanks for the Pull Request The pull request title isn't properly formatted. We ask that you update the message to match this format, as we use it to generate changelogs and automate releases.
Read more about contributing to ESLint here |
Are we planning to continue supporting node 10.x in the testing matrix? I didn't realize we were testing that far back. An issue with that is the tests have all been updated to use esm and won't work with that version of node. |
This comment has been minimized.
This comment has been minimized.
We should have tests on node 10.x since it's a supported version, but we can run there only tests against the CJS bundle. |
rollup.config.js
Outdated
// the espree package version is exported from the module (i.e., import { version } from "espree") | ||
// read version from the package.json metadata and write it into lib/version.js at build time, | ||
// since esm cannot import json by default | ||
const pkg = JSON.parse(fs.readFileSync("./package.json", "utf8")); | ||
fs.writeFileSync("lib/version.js", `const version = "${pkg.version}";\n\nexport default version;\n`); |
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.
Is this a common practice? We should revisit our release steps to make sure that package.json
has been updated before running this code.
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 don't know if it's common practice or not. Personally I don't see why the version number even needs to be explicitly exported from the module at all, but this seemed like an easy way to accomplish that without adding even more plugins and tooling.
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 think this is fine for now. In the future, Node.js will support JSON imports and we'll be able to remove this.
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 should modify our release process.
Current steps in generateRelease are:
npm test
npm version
to updatepackage.json
But we should have this order now:
npm version
to updatepackage.json
npm run rollup
to makelib/version.js
anddist/espree.cjs
.npm test
Maybe we could reorder the steps in generateRelease
(which is used for all packages, not just espree
) to calculate the new version and update package.json
before running npm test
, and also update the test
script to run rollup
before the tests.
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.
In the current esm PR, npm run rollup
implicitly updates lib/version.js
.
I did it this way because I don't know of any use cases where one would want to update version and not re-package the commonjs build in dist/
.
Co-authored-by: Milos Djermanovic <milos.djermanovic@gmail.com>
Can we add a script that will run all tests against |
Co-authored-by: Milos Djermanovic <milos.djermanovic@gmail.com>
Ehh maybe? I don't know how that would work though. All the tests are in esm with this PR.
blech... :( |
I would be more inclined to just say the hell with node 10, it goes out of maintenance in like 7 weeks. :P |
I didn't mean that only because of running tests on Node 10. CJS is still the main output (if nothing else, ESLint will use that entry point), we should be sure that it works. |
I just modified one of the tests to point at the cjs build: import "../../dist/espree.cjs"; This works ☝️ I guess it's a question of how to do this. Should all of the tests point at cjs, or is sufficient to just have a handful of them using the cjs build? |
If there is no other option, I'd vote that all tests work with |
Probably the right thing to do would be to create a series of tests that explicitly touch all parts of the public API that is exported, and asssert they are still accessible via cjs. Otherwise we are running a ton of duplicate tests, doubling the testing time, and over-complect-ifying the process. I think we really just need to assert that the public portion of the interface is still accessible, since that's all that is being changed. |
apart from node 10.x failing in CI, all the unit tests and lint rules should pass now. |
ok, seems all the tests at least pass now. I think the summary of remaining tasks that @mdjermanovic listed are pretty good, but I'll focus on two that are probably the most controversial and still need to be figured out:
|
I tried with the latest It worked locally on Node 12, but had to fix a CI issue with peer deps on Node 15 ( Here's a repo with those two commits on top of the latest commit from this branch: https://github.com/mdjermanovic/espree I think it works, all Node 12+ runs show Coverage doesn't work, but it doesn't work with |
Ah ok, well if it works we should use that I guess, since it's technically less change vs switching everything to |
@mdjermanovic I tried using the exact changes in your branch, and it fails for me locally: espree on master [!] is 📦 v7.3.1 via ⬢ v14.16.0
➜ npm run unit:esm
> espree@7.3.1 unit:esm /Users/mike/Sites/espree
> nyc mocha --color --reporter progress --timeout 30000 'tests/lib/**/*.js'
/Users/mike/Sites/espree/node_modules/yargs/yargs.js:1172
else throw err
^
Error [ERR_REQUIRE_ESM]: Must use import to load ES Module: /Users/mike/Sites/espree/tests/lib/acorn-after-espree.js
require() of ES modules is not supported.
require() of /Users/mike/Sites/espree/tests/lib/acorn-after-espree.js from /Users/mike/Sites/espree/node_modules/mocha/lib/mocha.js is an ES module file as it is a .js file whose nearest parent package.json contains "type": "module" which defines all .js files in that package scope as ES modules.
Instead rename acorn-after-espree.js to end in .cjs, change the requiring code to use import(), or remove "type": "module" from /Users/mike/Sites/espree/package.json.
|
oh, it does work! It turns out that |
regarding updating the
because these files don't seem to be in |
@mreinstein can you open an issue for the tool problem? I’d like to make sure we don’t lose track of that, and it’s probably not helpful to bundle with this PR. |
@mdjermanovic can you take a look to see if your concerns are addressed? |
We discussed the remaining tasks, and decided to:
There's already an open issue #471 to update |
hey, sorry to drop off the planet face for a while. Thanks for the status update. What are the remaining things that you'd like me to work on to get this PR into a completed state? |
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.
Sorry for the delay in reviewing!
I have only two small suggestions. One is to update lint scripts in package.json
(I left the suggested change). The other is to add a test with some JSX code to tests/lib/commonjs.cjs
.
Everything else LGTM
Co-authored-by: Milos Djermanovic <milos.djermanovic@gmail.com>
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.
LGTM, thanks for all the work!
All right, let's get this merged so we can move forward. 🎉 |
here's the new attempt, which attempts to satisfy all of the criteria listed in https://github.com/eslint/rfcs/tree/master/designs/2020-es-module-support
There are a ton of changes in here, but the bulk of them are trivial changes to
test/fixtures/*
which convert from cjs to esm.