build(deps-dev): bump web-ext from 6.5.0 to 6.6.0

[dependabot[bot]]

Bumps web-ext from 6.5.0 to 6.6.0.

Release notes

Sourced from web-ext's releases.

6.6.0

Features

• web-ext lint: updated to use addons-linter v4.4.0 (#2346, #2350)
  • Imported Firefox 94.0b8 and Firefox 95.0b8 API schema
  • Updated browser-compat-data
  • Updated to use eslint v8, which enables ECMAScript 2022 syntax (e.g. public field declaration and top-level await)
  • See all addons-linter changes: 3.20.0...4.4.0

Bug Fixes

• web-ext run:
  • fixed issues related to the nodejs 17 dns resolution behavior on systems where localhost is resolved to an ipv6 address (#2337)
  • fixed issue with removing temporary profile on nodejs <= 14.4 (#2344, saadtazi/firefox-profile-js#128)
  • deps: update dependency fx-runner to v1.2.0 (#2351)
• Fixed yargs module resolution issue on yarn 3.x + pnp (#2348)
• Wrap web-ext usage output at terminal width (#2329)

See all changes: 6.5.0...6.6.0

Commits

• b8143e5 chore: Bump package version for release 6.6.0
• 05e9fd5 fix: Set default adb host to 127.0.0.1 to prevent localhost resolution mismat...
• dbfc038 fix: Replace localhost with ipv4 to avoid ipv6 issue (#2339)
• f04c040 fix(deps): update dependency chrome-launcher to v0.15.0 (#2324)
• 12cebae fix(deps): update dependency addons-linter to v4 (#2350)
• 164af8c chore(deps): update dependency sinon to v12 (#2356)
• 5fa8b55 chore(deps): update dependency eslint-plugin-flowtype to v8 (#2355)
• c028a6c chore(deps): update dependency flow-bin to v0.165.1 (#2352)
• 39769ee chore(deps): update codecov orb to v3.2.2 (#2349)
• 6a3a015 fix(deps): update dependency fx-runner to v1.2.0 (#2351)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[rpl]

@AprilSylph I saw your comments on mozilla/web-ext#2245, but apparently those are gone now.

I looked a bit more into this and compared the behavior over your two repos, which was quite fascinating:

• your two package.json are really absolutely the same (the repo url is really the only difference between them)
• the two package-lock.json are different though, that is what makes the dependabot PR to work just fine in the other repo but not this one
• if you remove and recreate the package-lock.json in the other repo from scratch, that triggers the same issue in the repo where the PR does currently pass

The issue seems to be related to npm flattening and deduping dependencies, it looks that:

• node_modules/espree ends up to be the one related to your direct eslint dependency depends from, which is older of the one the addons-linter depends from
• node_modules/eslint ends up to be the one that addons-linter depends on, instead of the one that your package directly depends on

This makes the espree version used when the addons-linter imports it directly different from the one used by eslint (and also I got the feeling that it may also be making the eslint version used to lint your project different from the one that your package.json actually depends to, me at this point => :facepalm: )

The issue doesn't seem to be trigger if (unsurprisingly at this point):

• your package eslint dependency version is bumped to eslint v8
• or if the dependencies are installed using npm install --legacy-bundling (which basically doesn't do the flattening and deduping) or using yarn

Personally I'm fine to keep tracking this issue with that existing mozilla/web-ext#2245, even if technically I think that it is more likely that we will have to solve it in the addons-linter first.

While digging into it I got a couple of ideas to make sure the parser that is going to be used when the addons-linter create and runs its own ESLint instance internally to always match the one addons-linter depends directly on, but I want to evaluate those ideas with my colleagues before picking one, and so I'll get back to it on Monday.

In the meantime: thanks for reporting the odd different behaviors in you two repos, that was really helpful to investigate this issue more than I could before :heart:

[AprilSylph]

@rpl I'm glad this was enlightening! I removed the comments because I convinced myself that I was just dumb for not reading the release notes stating web-ext v6.6.0 was using eslint v8, but I was incorrectly assuming that npm shouldn't just resolve this stuff by itself. Thank you for the thorough assessment of the problem, and enjoy your weekend!

[nightpool]

this seems like an npm bug, no? why would node_modules/eslint use a version of eslint that's incompatible with the base package.json version specifier?

[dependabot[bot]]

Superseded by #87.