Please remove this 1.0.0 and increment the major version. It's full of breaking changes.

[stephenweaver]

Just spend 6 hours trying to figure out why all my react jest tests broke. an old package called enzyme uses this. and it's not pegged to "1.0.0-rc.12", all the jests test broke with the error

Test suite failed to run
ENOENT: no such file or directory, open 'node:stream'
import Adapter from 'enzyme-adapter-react-16';
at Runtime.readFile (node_modules/jest-runtime/build/index.js:1987:21)

This diff in insane for not bumping the major version
https://github.com/cheeriojs/cheerio/compare/v1.0.0-rc.12..v1.0.0

[Mister-Hope]

rc versions are just Release Candidate, there is no guarantee that at this stage there is no more breaking changes.

ONLY if cheerio introduce breaking changes in v1 stable versions, it must increase major.

[michaelfaith]

Yeah, while it's definitely uncommon for so much to change from an rc version and the first stable release, technically pre-release versions don't have to conform to any semver constraints. It's a pre-release.

[kabbagepatch]

It's a bit disappointing if all that can be said is "technically everything was done correctly, the rest is your problem", especially when a project has been in rc state for 2 years, with millions of downloads a week
I'm aware of many projects throughout the company I work at that are attached to certain Node versions, and it would be a significant development effort to uplift them all. Personally, I just hard-coded cheerio to 1.0.0-rc.12 in my project, and that's enough for me. @stephenweaver, see if that works for you. Hopefully others can find resolutions as well

[michaelfaith]

It's a bit disappointing if all that can be said is "technically everything was done correctly, the rest is your problem", especially when a project has been in rc state for 2 years, with millions of downloads a week

I'm not speaking with any authority here or justifying the decision; just saying that people shouldn't consider pre-release versions as stable.
I'd also say that expecting libraries to support ancient versions of node forever is a little unrealistic. Node 16 and earlier isn't being maintained anymore.

[stephenweaver]

@Mister-Hope @michaelfaith
Obviously, I agree that no semver laws were technically broken, but really? When the package has over 3 million downloads per week, no stable version in 8 years, and it hasn't been touched at all in 2 years; it's not huge leap to assume the inevitable and do your community a favor by simply giving that major version a bump. Doesn't seem like a huge ask to me 🤷

I don't expect libraries to support ancient version of node forever. I don't expect new major versions of libs to support EOL node versions. I do think that calling node 16 ancient when it's only been EOL for less than a year seems unnecessarily hyperbolic. I see you're a Principal at Atlassian, so I'm sure you understand that large 20+ year old fortune 500 companies have a hundreds of services of legacy code that's not always easy to get funding to keep on the latest versions of everything. Should we? Of course, but that's not the reality.

@kabbagepatch
Thanks for your comment. yeah, the fix was easy enough to pin the version once I figured out what happened. Fixed it before posting the issue here just to make it easier for the next person to figure out.

[michaelfaith]

Doesn't seem like a huge ask to me 🤷

Not at all. I certainly would have made different decisions if I were in their shoes, but I also wouldn't have left it in pre-rerelease for 8 years. So I can see how we got here. With that said, if they were going to do a band-aid rip like this, leveling up to the latest supported versions of node makes sense. And while, yes, I've worked on the corporate side of things for a long time, I can also sympathize with project maintainers who aren't getting sponsored to do this work fielding demands to do more.

[stephenweaver]

Absolutely. I would not advocate for making maintainers do a lot of work. Honestly, I'd never heard of this project until now (I spend most of my time these days out of the UI apps), but this is clearly a well loved package and the maintainers do excellent, un-thanked work.

But if we all agree that 1) we would have made a difference decision, and 2) that it's super easy to just delete the 1.0.0 package and republish as 2.0.0, then it seems like that is something work advocating for. I'm no asking for this release to support old versions of node. There are 1.4M public repos and 24K packages (public) that all depend on this library, and I would bet good money many of them are going to break because of this.

Granted our project only took a few hours to fix, but even if just 10% of the 1.4M public repo maintainers have to find and fix this and each spend just 1 hour on it that's 15 dev years. In our team's git org, which is probably less than 10% of the company repos, there are 76 projects that will break for the same reason ours did.

[Mister-Hope]

I understand your frustration, But before this 1.0.0 release, the ecosystem should ensure cheerio is correctly pinned with pre release. I'm not sure about the download number of the package you mention, but in the previous years, maybe we should expected that someone found the incorrect dependency range usage and send a pr to fix it. Anyway it is always necessary to pin any pre release version.

The only issue of cheerio team is leaving an pre released major for years which can confuse users, but not introducing breaking changes in the final stable release

[stephenweaver]

@Mister-Hope I'm not disagreeing if you, but there's an easy fix to help a good chunk of the 1.4M public repositories and countless private ones that depend on this package directly or through a dependency like we are. I really don't understand the backlash to this suggestion.

The package we are using in this legacy app is enzyme, which apparently is no longer maintained, and hasn't released a new version in 5 years. It didn't pin the version. This one package appears to also be widely used with 1M+ weekly downloads and depended on by 500K repos and 37k packages.

[shenqihui]

is this is a way?
like release 1.0.0 -> 2.0.0, 1.0.0-rc.12 -> 1.0.1 or 1.1.0 ? keep 1.0.0 ?

[mjancarik]

Hello,

We have same problem and problem with 1.0.0 version is that cheerio changed exports in package.json. Could you return back export declaration for lib/utils to package.json caab069 as desrcibe #3999?