search

cheeriojs / cheerio

The fast, flexible, and elegant library for parsing and manipulating HTML and XML.
https://cheerio.js.org
MIT License
28.7k stars 1.64k forks source link

Why not release 2.0.0?, all our repos are breaking without warning #4084

Open huangduo-myob opened 2 months ago

huangduo-myob commented 2 months ago
wartab commented 2 months ago

Cheerio was in RC, meaning it can change as it wishes until the official release. Pinning dependencies is crucial and especially crucial when using experimental packages.

tswaters commented 1 month ago

Maybe I'm missing something here, but rc12 is completely different to how the bundle looks from 1.0, and how it's consumed..... It goes from a "lib" directory with transpiled code (looks like es5 target, but I could be wrong) -- into type=module, a "dist" directory with js files having "import/export" statements..... and, "1.0.0" is an in-range update of "^1.0.0-rc.12"

For my two cents, I ran an npm update and jest started screaming at me about unexpected export syntax and failed all my tests. Anyone who is using enzyme in their scripts with jest and runs an npm update now has broken tests on their hands.... with npm8, adding the following to package.json will help -- at least until the dust settles and the ecosystem catches up:

+  "overrides": {
+    "enzyme": {
+      "cheerio": "1.0.0-rc.12"
+    }
+  },

I agree with OP. Publish 1.01 as an alias of 1.0.0-rc.12, deprecate 1.0.0, and publish whatever cheerio is today as 2.0

stanleyxu2005 commented 1 month ago

I am super excited and appreciate cheerio reaches a new milestone.

Cheerio 1.0 is out! After 12 release candidates and just a short seven years after the initial 1.0 release candidate, it is finally time to call Cheerio 1.0 complete. ...

Indeed. Normally a release candidate version should not introduce new breaking changes. And release candate version should just hold a small period of time, not 7 years....

It will be great, if it is possible to

  1. re-publish a version after rc12 without new breaking changes and
  2. release a v2.0 as well.
derwaldgeist commented 3 weeks ago

Same issue here. In my case, the changes broke our rollup compilation with super-weird issues (something pointing to the parsing of code tables). It took me hours to track down the root issue:

Another dev of our team had added ^1.0.0-rc2 to their repo, with a pinned package-lock.json. This worked fine, until I copied that dependency to another repo, when re-using said code, and did not have a package-lock.json containing the pinned down version. And bam, it broke the whole build process.

I can understand that a RC might still contain breaking changes. But if they are so fundamental, this can really break things unexpectedly. BTW: I wasn't aware until this point that a -rc2 prefix will automatically be resolved to the released version once it gets published.