Remove Node.js 12 support

[ybiquitous]

Node.js 12 reached End-of-Life on April 2022, and libraries removing the support have increased, e.g. Jest 29 (see #6308).

It seems reasonable that the next major version of Stylelint also would remove older Node.js versions.

[Mouvedia]

• update tsconfig.json
• update testing.yml
• upgrade yaml

[ybiquitous]

@jeddy3 What can we include other changes with the next major release than dropping the Node.js 12 support? Have we discussed it?

[jeddy3]

We haven't discussed it yet.

It's been a year since our last major release, so I think it's fine if we want to do another one.

Off the top of my head I can think of these other breaking changes:

• Move to ESM #5291 - Will dropping Node.js 12 support make this more viable?
• Remove support for processors #3408 - The above will probably need to involve this

There also offically deprecating the stylistic rules (non-breaking, though).

We should try to incorporate as many of our breaking changes as major releases can be troublesome for plugin authors. Having said that, I think we can put out a major release that only drops Node.js 12 support if moving to ESM isn't viable and it's too early to deprecate the stylistic rules.

What do you think?

[Mouvedia]

it's too early to deprecate the stylistic rules

If you don't have a drop-in npm package ready to replace these rules, their removal shouldn't be part of the release.

[ybiquitous]

@jeddy3 @Mouvedia Thanks for the feedback.

I agree with the following idea:

We should try to incorporate as many of our breaking changes as major releases can be troublesome for plugin authors.

So I think it's ideal for shipping both dropping Node.js 12 and adding ESM support in the same version. And, it doesn't seem there is a reason we need to hurry to drop Node.js 12 (as I know); it looks good timing that we revisit ESM support.

There also offically deprecating the stylistic rules (non-breaking, though).

We've already declared the following statement about the stylistic rules:

stylelint/docs/user-guide/rules/list.md

Line 260 in 4f59219

We have frozen these rules — we won't fix bugs nor add options, and we will deprecate then remove them in future releases. We recommend you use a pretty printer (like Prettier) alongside Stylelint rather than these rules. If you prefer to use Stylelint to enforce stylistic consistency, you can [migrate the rules you need to a plugin](../../developer-guide/plugins.md).

Based on the statement, I've rejected and closed bug reports or feature requests for the stylistic rules several times. So IMO, it seems to make sense that we deprecate the stylistic rules now. But,

If you don't have a drop-in npm package ready to replace these rules, their removal shouldn't be part of the release.

the opinion above also makes sense. Then, how about deprecating only rules handled by pretty printers (e.g. Prettier)?

stylelint/docs/user-guide/rules/list.md

Line 293 in 4f59219

### Handled by pretty printers

[Mouvedia]

how about deprecating only rules handled by pretty printers (e.g. Prettier)?

This is off-topic but Id say you would still need a plugin that cover the other 8 rules.
Even if it's just a copy-paste of the current stylelint rules without an appointed maintainer, it's better than dropping them and having ppl stuck on an old version.

[mattxwang]

Dropping Node 12 + switching to ESM in lockstep seems good to me as well! There is the knock-on effect of this helping out vscode-stylelint as well!

What's the best way I can help out here? I definitely have less experience than most of the core maintainers with the codebase/ecosystem, but I can definitely do lots of bite-sized changes (especially if they're somewhat tedious)!

[jeddy3]

And, it doesn't seem there is a reason we need to hurry to drop Node.js 12 (as I know); it looks good timing that we revisit ESM support.

I agree. The two dependencies requiring Node.js 14+ are dev ones. We can drop support for Node.js 12 at our leisure (unless a non-dev dependency puts out a Node.js 14+ release that addresses a security flaw).

What's the best way I can help out here?

This is an opportunity to revisit ESM support. So, the most helpful thing to do is to continue the investigation in #5291 to determine whether using ESM is viable for us, or if the various problems listed throughout that thread are still around (as a year has passed).

Then, how about deprecating only rules handled by pretty printers (e.g. Prettier)?

Yes, that's definitely an option. I'll create a new issue to discuss.

[mattxwang]

This is an opportunity to revisit ESM support. So, the most helpful thing to do is to continue the investigation in #5291 to determine whether using ESM is viable for us, or if the various problems listed throughout that thread are still around (as a year has passed).

Gotcha. Will see if I can take a stab at some of the smaller investigative tasks soon. On first glance, I don't think the issue with Jest has been resolved since it was last discussed in the thread; I'm not familiar with exactly how vscode-stylelint uses mocks, but skimming the release notes I don't see any big overhauls / changes.

I'll see if I can do any legwork off of your initial branch! Haven't used putout before, but perhaps can get something off of main.

[ybiquitous]

FYI, npm@9 seems to drop Node.js 12 support. See https://github.com/npm/cli/releases/tag/v9.0.0-pre.0

npm is now compatible with the following semver range for node: ^14.17.0 || ^16.13.0 || >=18.0.0

[ybiquitous]

Close via #6477

[Mouvedia]

@ybiquitous concerning v15 breaking changes, do we have a repository/package ready for the 8-rules plugin?
see #6311 (comment)

[ybiquitous]

do we have a repository/package ready for the 8-rules plugin?

No. Could you please open a new issue to discuss it?