Ship final version of 17.0.0

[voxpelli]

Me and @divlo shipped 17.0.0-0 today, #203, following the merge of #193.

17.0.0-0 is a prerelease.

One can install it using eslint-config-standard@next

Being a pre-release, 17.0.0-0 comes with no guarantees in regards to support / breaking changes etc. It exists to facilitate early feedback, from the wider community as well from our selves.

Next steps before we will ship a stable release of 17.0.0 are:

• Merge new standard-engine into standard: feat: update standard-engine to v15 standard#1754
• Ship a new major of eslint-config-standard-jsx
• Update standard to 17.0.0-0 of this module + the new major of eslint-config-standard-jsx
• Ship a 17.0.0-0 of standard to start getting some feedback on ecosystem compatibility
• When we're confident that the ecosystem is ready for a stable 17.0.0, roll one for this module...
  • Ship a 17.x compliant update to vscode-standard (Add support for Standard 17 vscode-standard#375)
  • All of the external tests in standard passes (Tracking issue test-external standard#1777)
  • standard-engine generated types (Generate and publish types standard-engine#279) + CI succeeds
• ...and then a stable 11.0.0 of eslint-config-standard-jsx
• ...and then a stable 12.0.0 of eslint-config-standard-react Not used, skipped
• ...and then a stable 15.0.0 of standard-engine
• ...and then a stable 17.0.0 of standard...
• ...and then new version of the long tail of standard-siblings, like semistandard...
• ...then close this issue and the 17.0.0 milestone

In the meanwhile, please report any breakage you discover 🙏

[voxpelli]

Prerelease 17.0.0-0 of standard is now released: https://github.com/standard/standard/releases/tag/v17.0.0-0

We will be checking the stability of this ourselves, but would love for as many of our users to test it out as well and report back to us whether it's time to party or time to head back into the workshop and reshape things. Thanks 🙏

[JanFellner]

Any update on the final 17? Working with it since 3 weeks, looking good to me...

[theoludwig]

Any update on the final 17? Working with it since 3 weeks, looking good to me...

This is in the hands of @feross, I already asked, if we could release it in early February on Discord but got no response.
Thanks for confirming that everything is working as expected.

[pgnd]

@feross
understand that there are many moving parts here before full release

could 'latest' tag, at least, be bumped to pick up dep change @

#215

? it's currently causing breakage, e.g. in VSCode's Redhat Dependency Analytics / snyk usage.

[voxpelli]

@pgnd What breakage is caused where?

The latest tag will and should always be pointing to the newest stable release.

@divlo We can release a stable before @feross chimes in, since its just a dependency update. We still have standard/standard#1777 to fix though

[pgnd]

@voxpelli
'breakage' in the Redhat Dependency Analytics scans. Which, atm, I'm less worried about ... since neither it, nor snyk, support yarn pnp (looking into a fix). generally, the whole vuln scan landscape is a sloppy mess re: pnp, afaict. will be interested to see whether @feross ' 'Socket CLI' addresses it correctly.

that said, this

yarn add --dev eslint-config-standard@https://github.com/standard/eslint-config-standard

temporarily cures the problem.

checking, here

yarn npm info  eslint-config-standard
{
  name: 'eslint-config-standard',
  description: 'JavaScript Standard Style - ESLint Shareable Config',
  'dist-tags': {
    latest: '16.0.3',
    next: '17.0.0-1'
  },

[voxpelli]

@pgnd I would need to get more details on the breakage to be able to address it.

Using yarn add --dev eslint-config-standard@next should work fine?

[pgnd]

@voxpelli understood. if i can get RH tool working in my env, I'll readd it and get the details to you. Atm, it's a 'doorstop'.

yarn add --dev eslint-config-standard@next

installs 17.0.0-1, from Jan 31 tag

which does NOT yet contain the relevant fix from

https://github.com/standard/eslint-config-standard/pull/215

[voxpelli]

#215 didn't mention it being a fix for anything?

[pgnd]

#215 (comment)
-->
#216

[chrisnruud]

a pre-release 17.0.0-2 tag could allow building transient dependencies that rely on eslint-plugin-n@latest without getting npm errors, that's all. We build an in-house eslint library for vue-cli5, and as of right now we have a breakage because of conflicting versions ubtil 17.0.0 i s released or a new beta tag is posted. If possible, we'd like to not do yet another fork of an eslint-related project 😅

[voxpelli]

I can try to roll one later, but if there’s no need for you to run with a newer version of eslint-plugin-n then you can simply downgrade it to the version that standard expects.

[JanFellner]

Ping :) I always need to manually handle the result of npm outdated for this repo. Any chance to get that done?

[voxpelli]

@JanFellner Feel free to help going through standard/standard#1777 :) That's the main blocker.

We won't release this as stable without having passing integration tests for the wider community as failures there can just as much mean that we had unintended rule changes in the ESLint 8 move as it can mean that the external projects have gone bad themselves.

Also: If you know of large projects using this that aren't present in the external tests there, then please make an issue or PR there to suggest adding them. The more insight we can get into community breakage / support, the more confident we can become in shipping things quickly.

(Right now I myself am pretty busy with my paid job, so haven't had time to look at the mentioned issues in a while)

[pgnd]

Feel free to help going through standard/standard#1777

looking, the aparently still open issues are

                                              LAST COMMIT
                                             _____________
https://github.com/feross/simple-get          2022-03-17
https://github.com/webtorrent/webtorrent      2022-03-30
https://github.com/marcbachmann/node-html-pdf 2021-05-07
https://github.com/feross/chrome-net          2020-10-29
https://github.com/libp2p/js-libp2p-tcp       2022-03-16
https://github.com/feross/safe-buffer         2020-10-29
https://github.com/yargs/yargs-parser         2022-02-27
https://github.com/maxogden/extract-zip       2021-08-01

Some are recently active, some, clearly ... aren't.

iiuc, no eslint8-ready eslint-config-standard v17x final release until each/all of those are updated? or replaced?

[theoludwig]

@pgnd

iiuc, no eslint8-ready eslint-config-standard v17x final release until each/all of those are updated? or replaced?

I don't think strictly that we should fix all the test-external before releasing v17, even if it would be better for sure, I don't think this is necessary as most of the failing ones are unmaintained repo with no activity recently, and also most of the repo in test-external still use var keyword to declare variables (they are mostly old codebases)...

I think it would be worth disabling some of them (see this file: https://github.com/standard/standard/blob/master/test/external/test.json).
Also, we might consider doing a major "refactoring" for this, and only do test-external for a repo that at least use v16 of standard and that is actively maintained (I know actively might be subjective but I think we should define what is "active" and we can pretty much agree that repo with no commits since 3 years is unmaintained), I saw some of them still using standard v14.

[Tofandel]

I agree, this also seems to be the backwards way of doing this, it's after all a major upgrade, so maybe there should be a PR for those projects to ease their upgrade, but if that PR is discarded or the project is not even using an up to date version of standard or their is no activity on the project they should definitely not block the upgrade in itself. I know some projects will be reluctant to change from var to const because they want to keep backward compatibility with the super old nodejs versions, and well we can't blame them for not wanting to release a major over code style (https://node.green/#ES2015-bindings-let this tells us that any project supporting node older than 6.4 cannot upgrade without a major and thus should be discarded)

Quick list of the ones to keep and remove:

• feross/simple-get: node >= 10 & active✔️
• webtorrent/webtorren: node >= 12 & active✔️
• feross/chrome-net: inactive no node version but already uses const ❌
• feross/safe-buffer: inactive no node version uses var ❌
• libp2p/js-libp2p-tcp: active node >= 16 ✔️
• marcbachmann/node-html-pdf: node >= 4 ❌
• yargs/yargs-parser: node >= 12 & active ✔️
• maxogden/extract-zip: node >= 10 but seems inactive ☑️

Adoption won't happen until it is fully released, and this creates opportunity for new projects to be impacted by this breaking change later on, and thus the sooner this happens the better, and those forgotten projects will either update in their own time or get forked into oblivion

[JanFellner]

@voxpelli whats your thinking about removing outdated packages as mentioned by @divlo and @Tofandel.
This currently seems to block the final shipment of v17?

[voxpelli]

whats your thinking about removing outdated packages as mentioned by @divlo and @Tofandel.
This currently seems to block the final shipment of v17?

I'm 👍 on that, though I want to go through them to see if the failures are because of an unintended change or because of eg. lack of maintenance on their path.

I'll try to find time soon to look at what eg. @Tofandel summarised here. Main blocker from my side has been my time 🙈

[voxpelli]

Okay, we have a release everyone! 17.0.0 is shipped, both for eslint-config-standard and standard 🎉