Release 14.0.0

[jeddy3]

Our work to be done:

• Remove deprecated rules #5290
• Remove function-calc-no-invalid #4731
• Remove syntax option #5289
• Remove Node 10 from CI #5292
• Migrate to PostCSS 8 #4942
• Fix cache  #5309
• Remove DisableReportRange.unusedRule #4899
• Add overrides property to configuration object #3128 (minimum for customSyntax)
• Remove configOverrides option #5522
• Add customSyntax option to configuration object #4843
• Fix CodeQL warning in indentation #5128
• Improve migration experience to customSyntax #5301

I believe these are the steps to releasing a version without any security warnings.

Non-blocking work we or the community needs to do:

• Prepare for stylelint version 14 vscode-stylelint#233 - Prepare VS Code extension
• Help us prepare for the next major release of stylelint stylelint-scss/stylelint-scss#541 - Create and publish stylelint-config-scss-standard

Non-breaking nice-to-haves:

• Remove isInteger polyfill #5219
• Refactor via fs/promises module #5271
• Refactor *-no-vendor-prefix to avoid using autoprefixer #5293
• Refactor to lodash-es #5294
• Add all options to configuration object #5142
• Move to ESM #5291

Non-blocking limitations:

• Fix multi-line double-slash command comments #5348

---

Release:

• stylelint release Prepare 14.0.0 #5604
• stylelint-config-recommended release Prepare 6.0.0 stylelint-config-recommended#123
• stylelint-config-standard release Prepare 23.0.0 stylelint-config-standard#198
• stylelint-scss release Prepare 4.0.0 stylelint-scss/stylelint-scss#547
• stylelint-config-recommended-scss release Prepare 5.0.0 stylelint-scss/stylelint-config-recommended-scss#84
• stylelint-config-standard-scss release Prepare 2.0.0 stylelint-scss/stylelint-config-standard-scss#1
• stylelint-demo update Update to stylelint 14 and related configs stylelint-demo#270
• stylelint.io update Update to stylelint 14 and related configs stylelint.io#227
• tweet (announcement (links to changelog and migration guide) + thanks) (follow up with VS Code)

Node 10 EOL is at the end of April. A lot of the packages we depend on will shift to Node 12 (and ESM) around then (see #5198 and sindresorhus/meta#15)

It'll be a major release of stylelint, so it's an opportunity to roll in other breaking changes. If you've got an itch to scratch that's a breaking change, then this is the time to do it!

We should remove deprecated code, e.g. #4899 and all the deprecated rules.

[ybiquitous]

If we can use dynamic imports, import-lazy may be needless:

stylelint/package.json

Line 128 in e25b5a2

"import-lazy": "^4.0.0",

[jeddy3]

Does node@12 supports dynamic imports? If so, that'll be great as we are reliant lazy/dynamic loading for performance.

[ybiquitous]

Oh, I missed that the --experimental-modules flag is necessary for Node 12, sorry 😓

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#browser_compatibility

---

Updated image:

[m-allanson]

I think the LTS release of node 12 supports ESM without a flag. See:

• https://github.com/nodejs/node/pull/37718/files
• https://nodejs.org/docs/latest-v12.x/api/esm.html#esm_modules_ecmascript_modules

[hudochenkov]

@m-allanson I think we talk about import().then(), not regular import.

[jeddy3]

Oh, I missed that the --experimental-modules flag is necessary for Node 12, sorry

Perhaps ESM (non-dynamic) with bundling will be our approach for 14.0.0. It'll give us:

• something that's future-facing (for dynamic ESM down the line)
• compatibility with our dependencies which will be shifting to ESM
• a non-performant version that can be installed directly from GitHub and tested against
• a performant version published to NPM with a small set of system tests
• browser compatibility

Steps towards this:

1. Deprecated and then remove problematic function-calc-no-invalid (Remove function-calc-no-invalid #4731 (comment)).
2. Investigate if there's a way to refactor the no-vendor prefix rules to avoid relying on autoprefixer (and the caniuse dataset); prefixes are on their way out in favour of browser flags, and perhaps maintaining a simple list in stylelint of vendor-prefixed properties used today is a simpler viable alternative.
3. Investigate ESM bundlers and compare their performance, particular ESBuild.
4. Investigate Jest's native support for ESM (we'll want to avoid transpiling for tests).

[alexander-akait]

Investigate Jest's native support for ESM (we'll want to avoid transpiling for tests).

Not ready yet, and I think will not ready in near future

[ybiquitous]

FYI. https://jestjs.io/docs/ecmascript-modules

It seems Jest's mocks do not work with ESM: jestjs/jest#10025

[jeddy3]

Thoughts on a node 14 minimum in 14.0.0?

We're such a small team of volunteers that I think we may need to jump to a minimum of node 14 if we are to stand a chance of migrating to ESM to maintain compatibility with our dependencies. As a dev tool, I think we can be progressive in the node versions we support.

We'd then be able to use dynamic imports for rules, syntaxes, formatters, plugins and processors, which will hopefully keep things simple and doable. If anyone fancies it, a proof of concept showing dynamic imports working (for just one of these parts) would be ace.

(It'd also be good to know if either method B or C will work with transpiling dynamic imports and Jest.).

[ybiquitous]

The idea sounds attractive to me. But the one thing that I’m concerned about is that perhaps many people will still be using Node.js 12 until it will be End-Of-Life on 2022-04-30.

For example, the following application will not be able to install stylelint 14:

• it has "engines": { "node": "12.22.0" } in its package.json
• and, it has engine-strict = true in its .npmrc

Such applications must continue using stylelint 12 or upgrade to Node.js 14. The task may be hard for some applications... 🤔

There is a more flexible but a bit complex way to use dynamic imports and require Node.js 12 as a minimum. In that case, people using Node.js 12 would have to specify the --experimental-modules flag such as NODE_OPTIONS=--experimental-modules stylelint *.css. We would describe such a workaround and promote users to upgrade to Node.js 14 in the document.

[jaydenseric]

Why is there a dilemma? With this level of support:

{
  "engines": {
    "node": "^12.20 || >= 14.13"
  }
}

You can use everything to do with ESM in Node.js except top level await, which is available unflagged since v14.8.0:

https://nodejs.org/dist/latest-v16.x/docs/api/esm.html#esm_modules_ecmascript_modules

Conveniently, this is also matches the minimum Node.js versions that support package subpath patterns.

I'm migrating all of my published packages to this level of Node.js support, and so are many other package maintainers (although some are lazy and incorrectly just update engines.node to >=12).

[ybiquitous]

@jaydenseric Excellent idea! 👏🏼 It should resolve any concerns!

[jeddy3]

Thanks for clearing that up. I hadn't realised dynamic imports are available in 12.20 without a flag.

I think we're good to proceed with moving to ESM with:

{
  "engines": {
    "node": "^12.20 || >= 14.13"
  }
}

Next steps:

• investigating dynamic imports
• investigating using Jest with ESM

If anyone fancies digging in, please do.

[qubyte]

One such package which has dropped support for node 10 is meow, which stylelint depends on. Version 9 is afflicted with this advisory in its dependency tree, which is resolved naturally in version 10. Version 10 of meow drops support for node 10 though, so updating to it would mean dropping node 10 support here too.

[jeddy3]

Thanks.

Meow 10.0.0 release notes and linked ESM migration guide:

How can I move my CommonJS project to ESM?

• Add "type": "module" to your package.json.
• Replace "main": "index.js" with "exports": "./index.js" in your package.json.
• Remove 'use strict'; from all JavaScript files.
• Replace all require()/module.export with import/export.
• Use only full relative file paths for imports: import x from '.'; → import x from './index.js';.
• If you have a TypeScript type definition (for example, index.d.ts), update it to use ESM imports/exports.
• Optional but recommended, use the node: protocol for imports.

[jeddy3]

I'm going to create separate issues for bits in the 14.0.0 release. I'll use this issue as an umbrella, and create an ordered checklist in the top post so that we have a clear set of steps.

[jeddy3]

I've created a v14 branch. I'm going to get the ball rolling by removing the deprecated rules (#5290).

[ybiquitous]

v14.0.0 may be a good chance to rename the main branch from master to main. What do you think?

[Mouvedia]

You forgot #5173. Will it have to wait version 15?

[jeddy3]

You forgot #5173. Will it have to wait version 15?

I can be included in a minor release due to our semver policy:

Might break your lint build: a bug fix in a rule that results in Stylelint reporting more errors