Custom extension id during development.

[Shubham]

Hi team, I am developing a chrome extension using manifest V3, multiple(>1) folks are working on it. We need to have a custom extension id which remains constant across diff machines and different builds. How is this possible?

[Deco]

You cannot have a custom extension ID - these are auto generated, what you can do however is have it be static by generating a .PEM file, and extract that ID to be used for hosting development locally across each respective build. 

See this guide for how the ID's work.

Cheers,
Deco

On Wed, 14 Jun 2023 at 12:58, Shubham <samile...@gmail.com> wrote:

Hi team, I am developing a chrome extension using manifest V3, multiple(>1) folks are working on it. We need to have a custom extension id which remains constant across diff machines and different builds. How is this possible?

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/c75d1cdc-13e6-4468-bc15-06db88b18f11n%40chromium.org.

[wOxxOm]

Yes, you can have a custom id, it won't be arbitrary, but it will be constant in unpacked extensions on any machine, which is what you need. You can do it by generating a "key" hash in your manifest.json, see https://stackoverflow.com/a/21500707

[Shubham]

Thanks for the response. Okay, so let me please reiterate my understanding in the below mentioned points. request you to please rectify if my understanding is not correct.
1. If I want to have a consistent extension id, I need to generate private and public key pairs. This can be done using, CRX Keys Generator - Plasmo Itero. Then I need to specify the generated public key in the "key" field of manifest. The corresponding extension id will be the first 32 characters of SHA256 hash of the public key. This extension id will be consistent across diff builds and different machines.
2. Now, if I want to use the same extension id in prod(for published extension) as well, then I need to specify the .pem file generated in the above step in chrome dashboard during submission. If this understanding is correct, then isn't it possible to have colliding ids?
3. If I don't want the self generated extension id, then I need to remove the key field before extension submission. So, during development, I will be having a "key" field in manifest but at the time of submission I have to omit it.

TIA

[wOxxOm]

The "key" in you rmanifest.json is not used by the web store, but you can include your original "key.pem" file used for generation of the id, which should preserve the id. The probability of a collision is low but I guess the web store would simply reject submission in case of conflict.

[Amy Dev]

You can also upload a draft extension to the developer dashboard and follow these instructions:
https://developer.chrome.com/docs/extensions/mv3/manifest/key/ 

[Shubham]

Will the same id be carried when the extension is published?

[wOxxOm]

Third time's a charm? Yes, it should be, unless something's changed recently.

[Cuyler Stuwe]

Alternatively, if all you want is a consistent ID during development (which doesn't need to match a CWS deploy), a team who are all using the same OS could just have the extension installed in the same path across all machines.

This is because the ID during development is actually derived from a hash of the path the extension is sideloaded from.

Although this isn't as "powerful" as the key-based method, there are a couple of advantages:

* I've had problems testing the various "update/restart" flows with extensions that have a "key" provided in the manifest (the extension ends up uninstalled on browser restart). Not sure whether this is still a problem (or whether it was ever intentional on Google's part), but this would avoid issues caused by this.

* For the right team, it could take a lot less work to figure out.

If you still want to use the key-based method, my minimal extension starter will have you set https://github.com/cuylerstuwe/chrome-mv3-template

npm run build:local-dev will fix your extension ID as part of a local build, setting the appropriate property in the manifest output.

npm run build:initial-deploy will build a deploy that's ready to send up to CWS.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/0df763d9-443e-417f-ba6a-a04620b9888cn%40chromium.org.

[Cuyler Stuwe]

Should note that my starter repo generally expects a POSIX-compatible (e.g., Linux/OSX) terminal with openssl available from anywhere.

It's been a while since I've done dev on Windows, but I think this might be satisfiable with Git Bash and maybe some reputable Windows source for OpenSSL.