Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Building issues with @parcel/config-webextension if we use custom manifest file name #8404

Closed
akash07k opened this issue Aug 18, 2022 · 13 comments · Fixed by #9068
Closed

Building issues with @parcel/config-webextension if we use custom manifest file name #8404

akash07k opened this issue Aug 18, 2022 · 13 comments · Fixed by #9068

Comments

@akash07k
Copy link

akash07k commented Aug 18, 2022

🐛 bug report

I'm building a web extension and I have separate manifests for both Chrome and Firefox.
Let's say my manifest is named manifest-firefox.json
So, if I try to build my extension by using parcel build src/manifest-firefox.json then it doesn't build the extension and doesn't even throw an error.
When I check the dist directory, I see that it has created only 1 file called: manifest-firefox.js
Whereas if I rename the original manifest file to "manifest.json" and use the command like: parcel build src/manifest.json
Then it successfully builds the extension. (PS: Manifest is unchanged in both the scenarios, only the file is renamed nothing else.)
So it seems that parcel has some bug where it doesn't work with custom named manifests.

🎛 Configuration (.babelrc, package.json, cli command)

I'm not using any babel config.
My .parcelrc is below:

{
	"extends": "@parcel/config-webextension"
}

🤔 Expected Behavior

Extension should be built correctly even though we supply custom manifest file name

😯 Current Behavior

The extension didn't built properly and I got only 1 file in dist directory named manifest-firefox.js with contents:
JSON.parse('{"//My manifest json here"}

💁 Possible Solution

🔦 Context

Trying to build extension for chrome and firefox with separate manifests

💻 Code Sample

"build-firefox": "parcel build src/manifest-firefox.json --no-content-hash --no-source-maps --dist-dir dist --no-cache --detailed-report 10"

🌍 Your Environment

Software Version(s)
Parcel 2.7.0
parcel/config-webextension 2.7.0
Node 2.7.0
npm/Yarn NPM 8.15.0
Operating System Windows 11
@fregante
Copy link
Contributor

@parcel/config-webextension only sets manifest.json as a supported filename. If you want a different name, you have to configure it, otherwise it just treats it as a regular JSON file.

"transformers": {
"manifest.json": ["@parcel/transformer-webextension"],
"raw:*": ["@parcel/transformer-raw"]
},
"runtimes": ["...", "@parcel/runtime-webextension"],
"packagers": {
"manifest.json": "@parcel/packager-webextension"
}

But I think it's easier to create firefox/manifest.json and chrome/manifest.json

@akash07k
Copy link
Author

@fregante
You are right buddy, I tried this approach too, but there the issue was that I was unable to reference my scripts from the manifests because they are lying in one level up.
For example, the structure is like this:
scripts,
firefox>manifest.json
chrome>manifest.json

Now I was unable to reference my scripts and was getting errors if I was using the syntax like:
"service_worker": "../scripts/background/background.js",
Am I missing something?
If there is any way to fix this, then I'll really appreciate it

@fregante
Copy link
Contributor

@akash07k
Copy link
Author

akash07k commented Aug 18, 2022

@fregante
Nevermind.
Fixed it.
The issue is certainly valid though.
Parcel should honor the custom manifest name too.
Certainly a parcel bug

@akash07k
Copy link
Author

akash07k commented Aug 18, 2022

@fregante
No, I'm not saying that.
I'm saying that simply if we use another name for the manifest like manifest-firefox.json, and supply the same name to Parcel build command, then too it doesn't build.
I fixed the second issue myself.
I'm not talking about it.
Read the issue description properly before commenting

@piotrwitek
Copy link

piotrwitek commented Sep 6, 2022

@fregante @akash07k as far as I can understand there is a misunderstanding in implicit knowledge on how to use @parcel/config-webextension.
I think the reason for confusion is that @parcel/config-webextension is using hardcoded manifest.json as manifest file name, but it's not mentioned anywhere in the web extensions getting started docs. A simple NOTE in the docs clarifying that the manifest.json name is hardcoded and mandatory would certainly save people hours of work.
Considering the recent push by google for migrations to manifest v3, a lot of cross-browser extension developers are starting to use separate names for manifest while previously they were usually always using manifest.json. Taking this into consideration would be a great win for all developers.

@akash07k
Copy link
Author

akash07k commented Sep 6, 2022

@piotrwitek Yes, you are quite right.
The fact that the manifest name is hardcoded should be mentioned in the docs, or it will be even better if the name customization can be allowed by setting some flags or environment variables.

@bentorkington
Copy link

Since the driver behind this seems to be the need to support two different manifest versions because of the Chrome Store MV3 fiasco, I was wondering if a useful feature might be a transformer that parses some sort of primary manifest file (which could be in JS or JSON5) and cooks it into the appropriate MV2 / MV3 format JSON manifest, depending on which parcel config file we use.

Wins:

  1. no duplication of mostly similar data to maintain
  2. can use comments in the manifest
  3. might be able to pull the version out of our package.json on the fly so there's only a single place to maintain it

@everdimension
Copy link

@akash07k How did you solve the issue with relative scripts and locales?

The problem I'm facing now, if I create separate manifests, e.g. src/production/manifest.json and src/development/manifest.json, I have to duplicate and copy the _locales folder to each of them, because there is no way to describe a relative path to the _locales folder in the manifest.json.

@akash07k
Copy link
Author

akash07k commented Nov 1, 2022

@everdimension
The best way which now use is to simlink your _locales directory.
By that, you won't be required to duplicate that dir either, and the workaround will also be made

@mischnic
Copy link
Member

mischnic commented Nov 1, 2022

Does this resolve everyone's concerns regarding different filenames for the manifest?

parcel-bundler/website#1052

@akash07k
Copy link
Author

akash07k commented Nov 1, 2022

@mischnic
Commented on that PR.

@github-actions github-actions bot added the Stale Inactive issues label May 24, 2023
@akash07k
Copy link
Author

akash07k commented May 24, 2023

Not stail

@github-actions github-actions bot removed the Stale Inactive issues label May 24, 2023
ALegendsTale added a commit to ALegendsTale/omnisearch-companion that referenced this issue Mar 1, 2024
+ Added support for chrome
+ Changes for manifest V3
= bgScript URLSearchParams was replaced with URL due to USP not working in Chrome MV3
= setBadgeText was separated into new function because browserAction was renamed to action in MV3
= Firefox remains on V2 because of the green dot permissions issue https://bugzilla.mozilla.org/show_bug.cgi?id=1851083
= Manifests have been given separate folder due to parcel issue parcel-bundler/parcel#8404
= Replaced @types/firefox-webext-browser with @types/webextension-polyfill as they both provide the same types & webextension-polyfill is in use for cross-browser compatibility of the Browser namespace
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants