-
-
Notifications
You must be signed in to change notification settings - Fork 10
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
Update meow dependency #41
Update meow dependency #41
Conversation
Update the source code from CommonJS to ES modules style. This consists of changing `require`s to `import from` statements, `module.exports` to `export` statements, and in some cases the structure of imports and exports as well. Notably when the old `require` statement also contained some additional logic, which is not possible with import statements.
Update the meow dependency to ^10.1.1 - which is the latest version - and update how it is used in accordance with breaking changes.
The migration to ES modules makes it more complicated to import config files. Most notably, config files can no longer just be `require`d. So, to read and parse config files, and to support ES modules and CommonJS config files, cosmiconfig was added to load config files.
Update the source to remove remaining `module.exports` reference (in parse.js). Update the source to be able to load rules as ESM using `await import(...)` (in rule-loader.js), update dependent code accordingly to await that import (see svglint.js). Two tests are now marked as skipped, initial investigation suggests the emitting of the "done" event at linting.js:79 doesn't work well in combination with async/await.
This comment has been minimized.
This comment has been minimized.
Update ESLint to the latest major version for easier support of a config file with an `.cjs` extension as well as better support for ESM. Fix all the linting warnings/errors.
The current status of this Pull Request:
This means that a major version bump would be required to release this - for the NodeJS version requirement and the lack of CJS support and the JS API change. @birjolaxew do you have any opinion on this? At the moment my opinion is leaning towards this solution - a mostly ESM-only solution with backwards compatibility support for CJS - because 1) it's simpler to implement and 2) it avoids any confusion due to someone trying to import an ESM config/plugin from the transpiled version of SVGLint. If you disagree, there seem to be libraries to de- Also, a correction to what I said before: not all v12 release of NodeJS support ESM, I believe (based on this) the first version with proper support is v12.20.0 (the latest v12, as of this comment, is v12.22.7). |
Change from the approach in 033d7db and replace the try-catch technique of importing by just using `await import`. From some local testing it seems only that one is ever used, making the catch branch effectively dead code. Additionally, this fixes a bug introduced in 1e4eb07 where CJS config files were imported but ignored since CJS is always `import`ed on the default property.
The first version with proper support of ESM is v12.17.0. But Here is the discussion: sindresorhus/meta#15 (comment). |
As 12.17 is the minimum required version for ESM support. 12.20 is the minimum required version if you want to use the `node:` protocol [1], which this project doesn't at the moment. -- 1. https://nodejs.org/api/esm.html#node-imports
No problem and thanks for the reply nonetheless, I was mainly interested in if you're okay with the major version change for this reason. I'll be doing some further testing to decrease the chances of any breaking changes affecting users that are using a compatible NodeJS version
Thanks for the feedback @sachinraja - I agree some of these are better as named exports, however my aim with this PR is to be a straightforward translation from CJS to ESM (+necessary changes to keep things working AND updating |
This looks good to me then 👍 |
Use the `"file://"` prefix when loading CLI config and rules to ensure importing always works on Windows.
Add a CommonJS version of the Node API of SVGLint by building it using Rollup [1]. Update the package manifest to allow for importing/requiring ESM and CJS (resp.) and `.gitignore` to ignore the generated CJS file. One "custom" Rollup plugin (provided by Rollup but not included by default) is used, namely `plugin-dynamic-import-vars` [2]. This plugin ensures that dynamic imports are properly handled as the CJS output generated by Rollup cannot dynamically import ESM rules. To make this work the rule-loader had to be updated as well, unfortunately the requirements of this plugin are quite strict and it is required that the `"../rules"` path is hardcoded into the `import` statement. Furthermore it has trouble detecting things that should be ignored, so errors are disabled to prevent errors due to dynamic imports of external plugins. -- 1. https://rollupjs.org/guide/en/ 2. https://www.npmjs.com/package/@rollup/plugin-dynamic-import-vars
I ended up trying to provide a CJS version of the API and I think I succeeded with f3e91a1. As a result this would now only be a breaking changes w.r.t.:
On the positive side, this would remove the need to migrate for API users. On the negative side, going full ESM in the future will require an additional major version bump (whether that's because we want to or because a not-CLI-only dependency goes ESM only). I'm personally of the opinion that we should go with the CJS support for now so that migrating is as easy as possible now and that the additional major version bump in the future isn't a huge deal. Does anyone in this thread have a different opinion? Additionally, I would appreciate if anyone who has time could try these changes out locally (just copy this repo into |
Just cloned locally and ran
|
@sachinraja npm link
svglint icon.svg
# Once you want to unlink
npm un -g svglint Or just run |
@ericcornelissen You could refer to this test if you want to test ESM behaviors. Also we can use execa to test our bin-script. The code will be: // test/cli.spec.js
import execa from 'execa';
const {stdout} = async execa('../bin/cli.js', ['--help']);
expect(stdout).toBe(helpText); |
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 to me. It would be better if the test can be improved.
It shouldn't matter whether I run it with node or directly (that's all the shebang at the top of the file is doing anyway) but I get the same error with that. I also get it when I link the package. |
Oh yes, you are right. I just missed some of your comments. I think you are using an unsupported Node.js version. Please refer to the FYI: https://docs.npmjs.com/cli/v8/configuring-npm/package-json#engines For more ESM knowledge you can refer to https://gist.github.com/sindresorhus/a39789f98801d908bbc7ff3ecc99d99c. |
Ah you're right, didn't notice that change. |
Thanks so much for all the help @LitoMore and @sachinraja! 😄
I agree they can be improved in the way you suggested, but, once again, I'd like to keep that for a later PR. For now I just want to be sure that running the CLI under normal circumstances on all major OSes and with all supported NodeJS versions works - i.e. doesn't error - I don't care so much about the actual output yet. It's currently just a smoke test. Also, just to be explicit about it, running with the
I added |
I just give a simple demo to show how to use |
Thanks once again @LitoMore and @sachinraja for feedback and testing 😃 |
🎉 This PR is included in version 2.0.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
No description provided.