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
Build CJS files via Rollup #7037
Conversation
I'll quickly explain the methodology for this PR: 1. remove each `lib/rules/*` for each deprecated test 2. remove each (now invalid) path from `lib/rules/index.js` 3. fix all broken tests, which fall into one of several categories: - tests that use a deprecated rule as an arbitrary rule; to resolve this, I just picked a different rule (usually `color-named` for `color-hex-case` and `number-max-precision` for `indentation`) - one of these is about a custom plugin, so I've rewritten the plugin - tests that are *about* deprecated rules; I added a `.skip` (have left comments in the review) - fs tests that use deprecated rules; I removed these from the config, then updated the snapshot. - the zen garden one doesn't work "out of the box" anymore, i.e. the snapshot has nontrivially changed because of indentation/spacing rules - `indentation`-specific behaviour (it being last); I deleted these! 4. remove all documentation related to removed rules (mostly `indentation`) 5. remove all unused utilities (via code coverage, not manual inspection)
Ref: #6979 (comment) Re-running the script indicates no newly-unused files: ```sh $ node scripts/find-unused-modules.mjs ```
Node.js 16.13.0 is the first version of Node.js 16.x LTS series. See https://nodejs.org/en/blog/release/v16.13.0
|
0c9dae3
to
188b9f6
Compare
For everything under
this steps are fairly complicated because it is a monorepo housing many different packages We switched to this strategy because building every plugin took to long and we didn't want CI duration to be a factor when deciding to create something new. In practice we found that it is very rare that more than one person is changing the same plugin at the same time. So we rarely have conflicts in build outputs. I can imagine that the same is true for Stylelint rules. We also added some git attributes to make it easier to resolve conflicts : https://github.com/csstools/postcss-plugins/blob/main/.gitattributes#L3-L6 When there is a conflict it will always result in a broken build output file, but that is fine. |
) `mergeTestDescriptions()` is used by deprecated rules. So I've created this commit from the `v16` branch, instead of the `main` branch. This change enables the `esModuleInterop` flag to prevent the following TypeScript error: ``` lib/testUtils/mergeTestDescriptions.mjs:1:8 - error TS1259: Module '"/Users/masafumi.koba/git/stylelint/stylelint/node_modules/deepmerge/index"' can only be default-imported using the 'esModuleInterop' flag 1 import merge from 'deepmerge'; ~~~~~ node_modules/deepmerge/index.d.ts:20:1 20 export = deepmerge; ~~~~~~~~~~~~~~~~~~~ This module is declared with 'export =', and can only be used with a default import when using the 'esModuleInterop' flag. ```
@romainmenke Thanks for providing the actual example. There are many pros and cons here. Checking built CJS files' validity on CI sounds good. 👍🏼 I'm concerned about verbose Git commit history. 🤔 |
I found an advantage in committing npm install github:stylelint/stylelint The second advantage is that we can easily compare |
Now ready for review! |
0542997
to
7176474
Compare
I'll quickly explain the methodology for this PR: 1. remove each `lib/rules/*` for each deprecated test 2. remove each (now invalid) path from `lib/rules/index.js` 3. fix all broken tests, which fall into one of several categories: - tests that use a deprecated rule as an arbitrary rule; to resolve this, I just picked a different rule (usually `color-named` for `color-hex-case` and `number-max-precision` for `indentation`) - one of these is about a custom plugin, so I've rewritten the plugin - tests that are *about* deprecated rules; I added a `.skip` (have left comments in the review) - fs tests that use deprecated rules; I removed these from the config, then updated the snapshot. - the zen garden one doesn't work "out of the box" anymore, i.e. the snapshot has nontrivially changed because of indentation/spacing rules - `indentation`-specific behaviour (it being last); I deleted these! 4. remove all documentation related to removed rules (mostly `indentation`) 5. remove all unused utilities (via code coverage, not manual inspection)
Ref: #6979 (comment) Re-running the script indicates no newly-unused files: ```sh $ node scripts/find-unused-modules.mjs ```
To prevent `npm run build` for consumers.
I'll quickly explain the methodology for this PR: 1. remove each `lib/rules/*` for each deprecated test 2. remove each (now invalid) path from `lib/rules/index.js` 3. fix all broken tests, which fall into one of several categories: - tests that use a deprecated rule as an arbitrary rule; to resolve this, I just picked a different rule (usually `color-named` for `color-hex-case` and `number-max-precision` for `indentation`) - one of these is about a custom plugin, so I've rewritten the plugin - tests that are *about* deprecated rules; I added a `.skip` (have left comments in the review) - fs tests that use deprecated rules; I removed these from the config, then updated the snapshot. - the zen garden one doesn't work "out of the box" anymore, i.e. the snapshot has nontrivially changed because of indentation/spacing rules - `indentation`-specific behaviour (it being last); I deleted these! 4. remove all documentation related to removed rules (mostly `indentation`) 5. remove all unused utilities (via code coverage, not manual inspection)
Ref: #6979 (comment) Re-running the script indicates no newly-unused files: ```sh $ node scripts/find-unused-modules.mjs ```
Node.js 16.13.0 is the first version of Node.js 16.x LTS series. See https://nodejs.org/en/blog/release/v16.13.0
) `mergeTestDescriptions()` is used by deprecated rules. So I've created this commit from the `v16` branch, instead of the `main` branch. This change enables the `esModuleInterop` flag to prevent the following TypeScript error: ``` lib/testUtils/mergeTestDescriptions.mjs:1:8 - error TS1259: Module '"/Users/masafumi.koba/git/stylelint/stylelint/node_modules/deepmerge/index"' can only be default-imported using the 'esModuleInterop' flag 1 import merge from 'deepmerge'; ~~~~~ node_modules/deepmerge/index.d.ts:20:1 20 export = deepmerge; ~~~~~~~~~~~~~~~~~~~ This module is declared with 'export =', and can only be used with a default import when using the 'esModuleInterop' flag. ```
@ybiquitous Thank you for already moving the migration to ESM along so far! I've been catching up on the discussions in #5291, and I wanted to check how we feel about #5291 (comment):
Is there any way for us to test this? |
@jeddy3 Good point. I think we should add a system test case to test importing ESM and CJS plugins in one config. For example: {
"plugins": ["./plugin.cjs", "./plugin.mjs"],
"rules": {
"cjs/foo": true,
"esm/foo": true
}
} However, please note that this case should fail now since the current Stylelint supports only stylelint/lib/augmentConfig.js Line 319 in 6765374
I think we need to change Any thoughts? |
I believe so. We can see if keeping backward compatibility is possible with our resources. How do we move forward with this pull request, e.g. shall we merge so we can keep moving forward with trying dynamic imports to uncover any potential issues? (I'm going offline for a week for a festival. I've approved the PR in case this is the route we want to go down, and I don't want to block you.) |
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.
Many thanks again for driving the migration to ESM forward!
I suggest gradually rewriting the current code to ESM to make each PR easier to review. I guess the most difficult part may be around importing (e.g. |
Ref #5291
Steps for this PR:
npm i -D rollup
rollup.config.mjs
.js
to.mjs
in ESM.mjs
. Following-up PRs will gradually migrate.js
files to ESM.Discussion points:
.cjs
files? => Yes.See https://rollupjs.org/
Note: This PR is still a draft, but I welcome any feedback. 👍🏼