v5 - Future about webextension-toolbox

[tm1000]

It's not a problem to support both because ultimately it's up to you as the developer in the end what you want to do

The breaking change in v5 will be removing the pollyfill. You can always add back the poly fill manually yourself but it won't be included anymore

[here-nerd]

My 2-cent: agree to @tm1000 to support both V3 and V2. Firefox has a plan to support MV3 (latest updated 27May2021). To the best of my knowledge, I don't think Safari says anything about MV3.

[csandman]

Actually nevermind, the @types/firefox-webext-browser is probably more appropriate for this.

[rthaut]

Regarding support for Manifest v3, will the goal be to support both v2 and v3 concurrently? Or would it be a full/hard switch to v3?

I realize that eventually there would be no need to support v2 at all, but I don't think all vendors will switch to v3 (and be stable) at exactly the same time. It would be unfortunate to need different versions of this tool depending on which browser (i.e. manifest version) is being targeted.

I know many developers will be facing non-trivial changes from v2 to v3, and, as such, would have no reason for supporting both v2 and v3 concurrently, but I have to imagine there are still many extensions that might face little to no changes for v3, so those developers may very well be able to release new builds for both v2 and v3.

Personally, I would like the ability to target the manifest version per browser/vendor, maybe even per browser/vendor + version, with the goal being to provide v3 builds where necessary while also having alternate (maybe "legacy" is a better term) builds for browsers that support v2.

[FezVrasta]

I think all major browsers already support V3 along V2, isn't it?

[tm1000]

The way @here-nerd achieved this is is by disabling the manifest validator for now.

For further progress see: https://github.com/webextension-toolbox/webextension-toolbox/milestone/1

[csandman]

As for the TypeScript support, it would be ideal if the browser type was recognized automatically. I know there is @types/chrome which can be used for supporting the global chrome variable and the browser variable could probably be pointed to using that. However, I am relatively new to TypeScript and haven't figured out the right way to do it post setup yet.

[tm1000]

@csandman nice find! We should put this in the docs. In master it already supports typescript

[csandman]

@tm1000 is it possible to use that TS implementation in the most recent version published on NPM?

[tm1000]

@csandman no I haven't published it because there's some other milestones I am trying to reach: https://github.com/webextension-toolbox/webextension-toolbox/milestone/1

[csandman]

Got it, well adding that type package to this package might be a good idea for having typescript work out of the box

[juharris]

Thanks so much for taking over this very helpful tool!

What else do you need this extension to do?
What would you like to see in future versions

I'm glad to see TypeScript support by default cause that was tricky to get working until I found the example. CSS importing help with TypeScript would be great too:

config.module.rules.push({
	test: /\.css$/,
	use: [
		'style-loader',
		'css-loader',
	],
})

More support so that new developers don't even know to think about webpack would be great. I'm struggling to find a good way to remove the unnecessary .ts and .tsx files in my build. I see that the base webpack config already uses 'clean-webpack-plugin' so it's weird for me to also use it with different settings (and I'm having some issues using it so I gave up on it and I'll just remove the files in bash).

Why did you choose this extension over https://github.com/mozilla/web-ext

I use it for building Emojit (Rate any page using emojis) for Brave/Chrome/Edge and Firefox. I like not really having to think about what browser I'm developing for.