101arrowz
101arrowz
If we're doing this, might as well support `runtime.getURL`. Though it's usually not used outside of content scripts, and if it's used in content scripts, you'll need to add it...
@avalanche1 After building with Parcel the two are identical. Globs are automatically expanded by the transformer for web extensions.
Just to clarify this issue, today you can do the following: ```js import yourCSSFile from 'url:./to-inject.css'; browser.tabs.insertCSS(id, {file: yourCSSFile}); // Similar for other import types ``` Also, `chrome.runtime.getURL` generally functions...
`__filename` is a Node + CommonJS thing, not a CommonJS thing - we can just find a replacement for `__filename` in CommonJS + browser (e.g. `document.currentScript.src` as shown above).
Might need to update the integration tests since we're now avoiding transforming `web_accessible_resources` - right now we test that `.jsx` is compiled.
I think the argument is that any files being added by the user into `web_accessible_resources` should be left as-is to preserve any qualities that external consumers need (e.g. a global...
I think that @louisgv is right about the majority of users of `web_accessible_resources` not wanting their files transformed. They're static assets in the majority of cases in my experience; in...
The problem with having it "raw by default" is that there's no current syntax for opting-in to the default transformation scheme (i.e. there's no named pipeline to tell Parcel to...
CSS Modules aren't currently supported in the web extension config. Although #7050 will fix this specific issue, it's still probably a good idea to work around name collisions in the...
This is probably a blocker for #8000; probably best to decide how exactly duplicate assets with different `bundleBehavior` should be bundled before deciding whether to merge generated dependencies or not.