Parcel takes a manifest.json
(not to be confused with normal web app manifest.json
) as the entry point, and handles the assets (HTML, JS, CSS, image files) defined in there. It copies them, as well as referenced assets inside, to ./dist
. Of course, assets will be processed if necessary, i.e., TS to JS, LESS to CSS.
Parcel only copies the manifest.json
to ./dist
.
Implements a new Asset handler for this.
When developing an extension for browsers, there are many different files in different places, i.e., background/index.ts
, popup/index.html
, devtools/index.html
, images/icon32.png
, inject/inject.less
.... However, they are all defined in the main manifest.json
, which makes it suitable for being the entry point.
Besides, Parcel does not handle multiple entry points nicely, yet.
I'd really love to see WebExtensions support in Parcel. Assets are currently per file-extension, and manifest.json
is too broad and could be used in a totally different context.
We would need something to discriminate WebExtensions manifest from other json
files. webmanifest
is used for Web Application manifests, perhaps using a dedicated extension? Not a big fan since it's not standard, but I don't see much alternatives. Any thoughts?
@fathyb I don't think we should be trying to guess weather the user is trying to bundle extensions, since both having a manifest.json
file doesn't necessarily mean it's a browser extension. Instead, I think we should have a --target
option which tells Parcel explicitly that you intend to package an extension.
I do agree that the lack of standardization is gonna be an issue since it's gonna be different across Chrome, Safari, Firefox, Opera, etc. So I think for now we should focus on chrome extensions only (they have the largest market share of extensions, and MUCH better documentation)
Side note: In the far future it would be really cool if Parcel could build a single extension into multiple browser targets, transpiling it for each browser to match the API differences.
Edit: Apparently there's this amazing thing called the WebExtensions API (spec), so pretty much all of what I said is false. Turns out that most browsers support this API (except Safari and a few others), so Parcel can just work based on that API.
I agree with @davidnagli . The user should not have to rename the extension. They should specify what the input type is.
And yes, we definitely want to follow WebExtensions API. There are some differences between browsers, but we can always base the support on Chrome as the initial prototype, and work out the differences later on.
Is this feature being worked on? Would love to have this for an extension I'm working on.
@ZY-Ang I moved development out to a plugin: parcel-plugin-web-extension.
const fs = require('fs');
fs.copyFile('./manifest.json', './dist/manifest.json', (err) => {
if (err) throw err;
console.log('COPIED');
});
just run this code before you bundle, This has been my workout for now.
@hkd987 yeah, I use shelljs to run a bunch of stuff including the build command
That's not really needed. Parcel works quite well with extensions when manually given the paths to build + using cpx
to copy the assets (including manifest.json):
"scripts": {
"dev:parcel": "parcel --no-autoinstall --port 9090 --no-hmr src/**/*.html src/background/background.ts src/content-scripts/*.ts",
"dev:cpx": "cpx 'src/**/*.{json,png,svg}' dist --watch --verbose",
"dev": "npm-run-all clean --parallel dev:parcel dev:cpx",
"build:parcel": "parcel build --no-minify src/**/*.html src/background/background.js src/content-scripts/*.js --public-url ./",
"build:cpx": "cpx 'src/**/*.{json,png,svg}' dist",
"build:extension": "run-s build:parcel build:cpx",
}
Parcel really makes developing webextensions a breeze. Many thanks to the authors!
This will be officially added to Parcel core by #5304, which supersedes #3439. If you'd like to test out the PR, it would be much appreciated.
That's not really needed
"Not needed", but you need 6 complex and incomplete lines of configuration instead of 2 that look like parcel build manifest.json
and parcel watch manifest.json
. I think it's very well worth it
Most helpful comment
@ZY-Ang I moved development out to a plugin: parcel-plugin-web-extension.