cheerio: After the release of `v1.0.0-rc.11`, `Module parse failed: Unexpected token` occurs

I resolved this problem by declaring cheerio in devDependencies like:

  "devDependencies": {
    "cheerio": "=1.0.0-rc.3",
    ...

Hope this helps.

People might not be able to upgrade a library, if that’s actually brought in by other modules (e.g. via create-react-app). Changes that require upgrades of other libraries should always be accompanied by at least a minor version increase.

Locking package import to cheerio@1.0.0-rc.10 fixed the issue for me. But that should really not be needed! Please do such changes in another release that raise at least the minor version number, so they are not automatically picked up.

1.0.0-rc.11 is an issue for me because of the ECMAScript Modules used in parse5-htmlparser2-tree-adapter 7.0.0 …

The breaking change on parse5-htmlparser2-tree-adapter v7 is well documented : https://github.com/inikulin/parse5/releases/tag/v7.0.0

This is a shame, that this package (cheerio) bump its dependencies (with major change) without a major change on its version … It cost me hours of debugging -_-

How i landed here ? I’m here because cheerio is a dependencies of an dependencies of MJML (that I use)! (I remove node_modules and when I yarn install again because people do not handle correct semver everything explode)

Spend hours to find this => MJML > mjml-core > juice > “cheerio”: “^1.0.0-rc.10” > parse5-htmlparser2-tree-adapter 7.0.0

Cheerio go to 1.0.0-rc.11 with parse5 v7 ==> all lib which use “cheerio”: “^1.0.0-rc.10” will potentially blow up …

So, please next time read the changelog before up the dep…

Meanwhile, here my fix :

if you use yarn, add these lines in package.json :

 "resolutions": {
    "cheerio": "1.0.0-rc.10",
    "parse5-htmlparser2-tree-adapter": "^6.0.0"
}

if you use npm, add these lines in package.json :

 "overrides": {
    "cheerio": "1.0.0-rc.10",
    "parse5-htmlparser2-tree-adapter": "^6.0.0"
}

Ressources https://docs.npmjs.com/cli/v8/configuring-npm/package-json#overrides https://classic.yarnpkg.com/lang/en/docs/selective-version-resolutions/

Lock the dependency to a version that still uses htmlparser2 v7

Just my 2 cents here basing on this comment. I’m not a cheerio but htmlparser2 user. For me locking htmlparser2 dependency to ~7.0.0 in package.json resolutions did the trick. If you’re using Yarn you can try out this.

"resolutions": {
    ...
    "htmlparser2": "~7.0.0"
}

@mike-lischke Do you know a way to lock the package version on lerna?

In my project, enzyme is using cheerio. I couldn’t find a way to lock the subdependecy of enzyme. I tried npm-force-resolutions and overrides. But unfortunately lenra does not support them 😦

I want to emphasize that this is not a cheerio issue. The issue lies in the newest version (8.0.1) htmlparser2 dependency, which has a file using syntax webpack doesn’t understand. So to fix the issue, check if any of your dependencies are using that version of htmlparser2 by running:

npm ls htmlparser2

Revert all those dependencies to previous versions where they use htmlparser2 version 7.2.0 or less.

I have the same issue. help me.

To add to @ItzLarz: Modern versions of Webpack do understand the relevant syntax, so an upgrade will resolve this issue as well. See https://github.com/fb55/htmlparser2/issues/1237#issuecomment-1182522861 for more solutions.

god

@yanglbme @gladson1976

As a side note, enzyme recommends locking cheerio version as =1.0.0-rc.3.

https://github.com/enzymejs/enzyme/issues/2559#issuecomment-1133812922

Lock the dependency to a version that still uses htmlparser2 v7

Just my 2 cents here basing on this comment. I’m not a cheerio but htmlparser2 user. For me locking htmlparser2 dependency to ~7.0.0 in package.json resolutions did the trick. If you’re using Yarn you can try out this.

"resolutions": {
    ...
    "htmlparser2": "~7.0.0"
}

Can confirm this also worked for me (for me htmlparser2 is coming from sanitize-html, but we also use enzyme on its own). I was testing resolving cheerio and parse5-htmlparser2-tree-adapter, but I no longer need to - resolving htmlparser2 is enough by itself.

I resolved this problem by declaring cheerio in devDependencies like:

  "devDependencies": {
    "cheerio": "=1.0.0-rc.3",
    ...

Hope this helps.

Seriously a life saver, thank you.

yes the equal to sign “=” in the statement helped me solve my issue too thankyou

@ljharb This is actually a separate issue 😄 — #2547 was fixed in #2601, which is included in the latest release. The issue here is that some old (but not too old) Webpack versions will struggle with export * as X from 'y' in the ESM module.

parse5-htmlparser2-tree-adapter is a dual ESM and CJS module and shouldn’t need this workaround.

lock the version in dependencies, like this doocs/md@551b07d

works fine when it is referenced in dependencies… I had added in the devDependencies earlier…

lock the version in dependencies, like this https://github.com/doocs/md/commit/551b07d46df7136e5758b418a62bcec3c9bb52f5

The bundler is choking on export * as DomUtils from "domutils";. It seems like Webpack has supported the export * as ... syntax since ~2020 (see https://github.com/webpack/webpack/commit/3cf8299602b468ae0291779cd57c7fed3037b7f6), and an update should fix things. Alternatively, you could also force the bundler to pick up the CommonJS code that’s still shipped with Cheerio.

For https://github.com/umijs/umi/issues/8109: umijs seems to have switch to rollup afaict (at least I haven’t been able to find a Webpack version), so there is a chance that updating some internal packages might do the trick?

Please let me know if this makes sense!