Ship final version of `17.0.0`
voxpelli opened this issue · comments
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-engineintostandard: standard/standard#1754 - Ship a new major of
eslint-config-standard-jsx - Update
standardto17.0.0-0of this module + the new major ofeslint-config-standard-jsx - Ship a
17.0.0-0ofstandardto 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.xcompliant update tovscode-standard(standard/vscode-standard#375) - All of the external tests in
standardpasses (standard/standard#1777) -
standard-enginegenerated types (standard/standard-engine#279) + CI succeeds
- Ship a
- ...and then a stable
11.0.0ofeslint-config-standard-jsx -
...and then a stableNot used, skipped12.0.0ofeslint-config-standard-react - ...and then a stable
15.0.0ofstandard-engine - ...and then a stable
17.0.0ofstandard... - ...and then new version of the long tail of
standard-siblings, likesemistandard... - ...then close this issue and the
17.0.0milestone
In the meanwhile, please report any breakage you discover 🙏
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 🙏
Any update on the final 17? Working with it since 3 weeks, looking good to me...
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 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
@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'
},
@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?
@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
#215 didn't mention it being a fix for anything?
#215 (comment)
-->
#216
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 😅
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.
Ping :) I always need to manually handle the result of npm outdated for this repo. Any chance to get that done?
@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)
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?
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.
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
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 🙈
Okay, we have a release everyone! 17.0.0 is shipped, both for eslint-config-standard and standard 🎉