feat: add firefox build

[lkuoch]

Description

• This change adds a firefox build stage to this extension which outputs a firefox compatible extension.
• Let me know if there's a different way you prefer. I know writing a webpack extension might be a bit overkill... but it works 🤠

To install locally on firefox

• Run yarn build:firefox
• In firefox, navigate to url about:debugging
• Click on This Firefox and Load Temporary Add-on... and add build/manifest.json

[gatlinnewhouse]

For the Firefox signing of the extension to work (so it eventually can be on Firefox's extensions page) it will need a package version that generates as something other than {{package_version}} in the build directory, at least if I try to use Mozilla's web-ext tool to build an crx file of the extension. As it stands, web-ext can build a .zip file for testing right now

[warrenday]

Hey @lkuoch thanks for working on this.

I'm not sure a webpack plugin is the best place for this. We already have a pattern in place for post-build work via postbuild scripts. For example, the manifest.version is already set with set-manifest-version.

I think it would be cleaner to just update the postbuild script with something like a prepare-package script which does:

1. update manifest.version
2. update manifest.manifest_version
3. Switch out devtools for chrome/firefox

Since the actual bundled code doesn't change I think it's more logical to avoid webpack in this case.

What do you think?

[warrenday]

Just to add to this, the build command could just produce both a chrome and firefox extension in one go. Maybe produce both:

build/firefox
build/chrome

We would always want to release to both at the same time anyway, so seems beneficial to just produce both bundles with one command. This would also mean postbuild can handle both bundles in one script.

[lkuoch]

Hey @lkuoch thanks for working on this.

I'm not sure a webpack plugin is the best place for this. We already have a pattern in place for post-build work via postbuild scripts. For example, the manifest.version is already set with set-manifest-version.

I think it would be cleaner to just update the postbuild script with something like a prepare-package script which does:

1. update manifest.version

2. update manifest.manifest_version

3. Switch out devtools for chrome/firefox

Since the actual bundled code doesn't change I think it's more logical to avoid webpack in this case.

What do you think?

This does sound reasonable given that it works already

Originally I was thinking to just have a post script that does all of this since I saw that it was done for the package version already.

For it to be built for firefox, multiple places needed to be touched eg: (change manifest version + swap out devtools.js content and delete the devtools.firefox.js file).

There could potentially be more changes in the future such as moving in the package version so I thought it might get too complicated just having a separate build stage after webpack. I think letting webpack handle that process made it much simpler and could reducer the whole process from build -> post-build to just build.

Just to add to this, the build command could just produce both a chrome and firefox extension in one go. Maybe produce both:

build/firefox
build/chrome

We would always want to release to both at the same time anyway, so seems beneficial to just produce both bundles with one command. This would also mean postbuild can handle both bundles in one script.

Webpack is already bundling / copying the files so makes sense to continue with using webpack to do postbuild possibly.

[lkuoch]

For the Firefox signing of the extension to work (so it eventually can be on Firefox's extensions page) it will need a package version that generates as something other than {{package_version}} in the build directory, at least if I try to use Mozilla's web-ext tool to build an crx file of the extension. As it stands, web-ext can build a .zip file for testing right now

Yup yup, I'm assuming to release the extension it would go through build:firefox -> postbuild to populate the package version.