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

[webextension] Allow dynamic manifest.json #8138

Closed
ngustavo opened this issue May 24, 2022 · 11 comments
Closed

[webextension] Allow dynamic manifest.json #8138

ngustavo opened this issue May 24, 2022 · 11 comments
Labels

Comments

@ngustavo
Copy link

🙋 feature request

Everytime I update the extension, I must manually update manifest.json. It would be nice if I could use a manifest.js and get the version and other info directly from package.json.

🤔 Expected Behavior

Allow usage of manifest.js or add the option to get info from package.json.

😯 Current Behavior

It only accepts a manifest.json

💁 Possible Solution

Expect besides a JSON file, a JS object, a default export of JSON string or read from package.json.

🔦 Context

I'm trying to automate some upgrade tasks and I don't see any way of achieving this.

💻 Examples

This is possible with Rollup and Webpack:
https://github.com/crxjs/chrome-extension-tools

@louisgv
Copy link
Contributor

louisgv commented May 24, 2022

I'm working on a browser extension framework that uses Parcel underneath, and it basically does exactly what you described (i.e, the manifest is generated for you and the version and so on are taken from package.json). Feel free to check out the docs :D

@mohsen1
Copy link
Contributor

mohsen1 commented Jun 25, 2022

This could be very useful for me. At the moment I have a a little pre-build script that writes manifest.json to disk before building.

@fregante
Copy link
Contributor

Accepting manifest.json.js sounds like a good idea. Having a dynamic output covers a lot of cases (development-only settings, per-browser bundles, testing, etc)

@devongovett
Copy link
Member

This would make caching and watch mode a lot more difficult. JS files can produce non-deterministic results, or may have dependencies on other files, npm packages, environment variables, etc. This is all very hard to track correctly, which is why we generally discourage JS-based config files. I would be hesitant to add another one.

@fregante
Copy link
Contributor

fregante commented Jun 29, 2022

How is this different from any other file (as far as the dependencies are concerned)?

// index.js
- import('./alpha.js')
+ import('./beta.js')
// manifest.json.js
export default {
	background: {
		scripts: [
-			"bg.js"
+			"background.js"
		]
	}
}

They both change the graph. The only difference is that index.js appears "as is" in the dist whereas manifest.json appears "as exported"

@devongovett
Copy link
Member

devongovett commented Jun 29, 2022

Because it isn't bundled, it's executed and the results are written. So anything that might change those results needs to invalidate the cache, not just the file itself.

@ngustavo
Copy link
Author

Maybe evaluate that JS on load and turn it into a string object or JSON? That way we could still read environment variables and other configurations before bundling.

@github-actions github-actions bot added the Stale Inactive issues label Dec 27, 2022
@mischnic
Copy link
Member

There could be some kind of JSON templating transformer that replaces {{something}} with the actual result (so this wouldn't be specific to manifest.json, just any JSON files)

@github-actions github-actions bot removed the Stale Inactive issues label Dec 27, 2022
@LeoDog896
Copy link
Contributor

With the templating system, it may be a good idea to use enviornment variables (it turns out that NPM has env variables for package versions, names, and other fields) - maybe a seperate issue / discussion should be raised for this new transformer?

@101arrowz
Copy link
Member

Part of the templating issue can be solved by using a custom transformer. Previously there were issues because the entry asset had to be manifest.json, but that should be fixed in this PR: #9068

Copy link

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs.

@github-actions github-actions bot added the Stale Inactive issues label Nov 30, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

8 participants