Webextension fixes

[101arrowz]

↪️ Pull Request

Don't use shared dependencies for manifest children, allow browser_specific_settings, and fix web_accessible_resources generation for the web extension config.

Fixes #7952
Fixes #7953 (mostly)
Fixes #7050 (comment) (we should support this key since it's sometimes mandatory in Firefox)

[devongovett]

Looks good, can you fix the linter?

[101arrowz]

This broke a few things actually, let me try to fix first.

EDIT: It looks like parallel priority doesn't actually work reliably for repackaging. It only seems to update when you add the first CSS asset, and doesn't work at all for other asset types.

[101arrowz]

@devongovett I think we're going to need a new type of invalidation for packagers to properly support web extensions. The only reason adding CSS into JS works when the parent is an HTML is due to the CSS packager concatenating assets into a single bundle. Maybe invalidateOnBundleChange(bundle, { children?: boolean }) or something. For this packager we'd need to invalidate whenever any recursive child OR sibling OR recursive child of a sibling was invalidated, which might be a bit tough to implement...

[101arrowz]

Doing all of the changes to actually fix the packager will actually take substantially more time so I'll mark this as ready for review again and will submit a separate PR to potentially revamp packager caching later. At the moment everything still works, just not for hot reload.

I'm thinking that since the bundle graph is provided in its entirety to each packager, package requests should also include the hash of the bundle graph in their IDs (which makes hashing the bundle redundant) or at least there should be a way to invalidate the cache from the packager.

[101arrowz]

Just realized this now breaks importing stuff from content scripts but I'm not going to be able to fix for a few days, plus I don't want to overload you guys with so many PRs.

[Stvad]

getting the following with latest nightly now, is that the issue you refer to @101arrowz or should I report a separate one? :

Error: Cannot read properties of undefined (reading 'hashReferences')

  TypeError: Cannot read properties of undefined (reading 'hashReferences')
  at getBundlesIncludedInHash
  (/Users/vlad/coding/experiments/embed-fragments/node_modules/@parcel/core/lib/requests/WriteBundlesRequest.js:147:47)
  at getBundlesIncludedInHash
  (/Users/vlad/coding/experiments/embed-fragments/node_modules/@parcel/core/lib/requests/WriteBundlesRequest.js:151:7)
  at assignComplexNameHashes
  (/Users/vlad/coding/experiments/embed-fragments/node_modules/@parcel/core/lib/requests/WriteBundlesRequest.js:140:105)
  at Object.run
  (/Users/vlad/coding/experiments/embed-fragments/node_modules/@parcel/core/lib/requests/WriteBundlesRequest.js:115:5)
  at async RequestTracker.runRequest
  (/Users/vlad/coding/experiments/embed-fragments/node_modules/@parcel/core/lib/RequestTracker.js:725:20)
  at async Object.run
  (/Users/vlad/coding/experiments/embed-fragments/node_modules/@parcel/core/lib/requests/ParcelBuildRequest.js:74:20)
  at async RequestTracker.runRequest
  (/Users/vlad/coding/experiments/embed-fragments/node_modules/@parcel/core/lib/RequestTracker.js:725:20)
  at async Parcel._build
  (/Users/vlad/coding/experiments/embed-fragments/node_modules/@parcel/core/lib/Parcel.js:397:11)
  at async Parcel._startNextBuild
  (/Users/vlad/coding/experiments/embed-fragments/node_modules/@parcel/core/lib/Parcel.js:298:24)
  at async $b0fd219fea43bcac$export$2e2bcd8739ae039._runFn
  (/Users/vlad/coding/experiments/embed-fragments/node_modules/@parcel/utils/lib/index.js:32427:13)

[101arrowz]

That issue is probably just a caching bug (at least I had that issue before and it started working after I cleared my cache). If not, refer to #4145.

[Stvad]

Trying this again in v4.5 and clearing cache (rm -rf .parcel-cache/) didn't help, will explore that issue, though at a glance does not seem to have a consistent solution =\