In my opinion, Firefox imposes complex constraints on casual developers, and web-ext is part of it.
I have a few web extensions I wrote in order to customize a few web sites (automate tasks, alter display, etc). After a Firefox update, they were not allowed anymore, because they're not signed. The extensions page cannot load local extensions. Then I discovered the secret debug-extensions page of Firefox where I could load them.
Unfortunately, Firefox removes local extension when it closes. I had the choice between loading each local extension after launching a new Firefox, which mean a dozen of clicks, or installing web-ext in order to sign my extensions, and sign them again after each change (no idea if there were extra actions needed in the process, like manual reload). I opted for a much simple option: with Chromium-based browsers, you can enable the extension-developer mode, and then you're allowed to load local extensions from the normal extensions page. Extensions are kept across restarts.
I had the same issue but i solved it by using Firefox Developer edition instead which allows you to install unsigned extensions. This allowed me to use my Firefox profile (by manually copying the files over the existing profile files) which i have going back several years now.
If that ever changes i'll look into making my own Firefox binaries or whatever that have this check removed.
Does the unbranded stable build have automatic updates yet? Last time I checked (which was quite a while ago) it didn't, which made using it day-to-day seem like a bad idea. I'd totally switch to it if I can just use it normally.
This updates frequently since it is basically Firefox beta (though in practice i never had any issue). Note that this has telemetry enabled by default so you may want to disable it via the options.
The unbranded stable isn't updated automatically so you'll need to check for new versions yourself (shouldn't be too hard to automate it with a python script or whatever that runs via cronjob or windows task scheduler and notifies you for new versions).
I think the argument is that if you’re knowledgeable enough to write an extension you can switch to the “I know what I’m doing version” and let everyone else reap the benefits of malware protection.
They don't document it well but they will sign pretty much anything over the web so long as you're not distributing it on add-ons.mozilla.org (AMO). You don't have to use web-ext.
There isn't even a manual review gate for AMO releases after the first one (but it can happen after that fact).
I find Mozilla's policies friendlier than Google's but this is the first I've heard of "extension developer mode" - will have to look into that as my extension is cross browser.
It might be a bit tiresome if you make regular changes but you can have mozilla sign your extension without having to wait for them to review or place it on AMO.
They get an archive of stuff they can (theoretically) ban if found to be malware. Which I guess (or rather I hope) spreads a bit of a chilling effect among potential malware writers.
I feel you, while the debugging option is handy for development, it is annoying that you can't easily install the extension permanently.
The way I do it now is to package the extension as zip (no webext needed) with a custom manifest, which can be installed by setting xpinstall.signatures.required to false in the about:config page.
On the manifest side, you just need to include this snippet:
you can sign up for a free account on mozilla's site to sign personal extensions without any oversight as long as you don't select the option to list it on the marketplace. (even that is free but it requires a bit more review on the part of mozilla)
Little known fact: web-ext not only can launch both Firefox and Chrome in a new profile with the extension preloaded, but it will also refresh them when any of the extensions’ files changes.
> it will also refresh them when any of the extensions’ files changes.
I don't see that in the docs. would it support webpack? for now, I'm using webpack-extension-reloader plugin for an extension I built for Notion.so and it works (reload) for chrome.
https://github.com/GorvGoyl/Notion-Boost-browser-extension
Not really. I would prefer to keep my profile which has all my history, sessions etc instead of launching a new Firefox every time. Reloading extensions is really not that hard, especially with something like https://chrome.google.com/webstore/detail/extensions-reloade...
I'm sorry, but I seem to not understand how that extension is better than web-ext. web-ext reloads the extension automatically when it changes on disk, "Extensions Reloader" seems to require you to either click a button to reload, or setup your build system to redirect current browser session to "http://reload.extensions", both inferior solutions to just using web-ext.
I've been using webextension-toolbox[1] for a few years now to develop cross-platform extensions and it's worked really well. I always got the feeling other browsers other than Firefox were Second-class citizens with web-ext (if supported at all) whereas with webextension-toolbox they all appeared to work out of the box.
The first time I tested my extension on Firefox after developing it one Chrome for months it worked the first time. I was so shocked how seamless it was I actually thought something must be really wrong, it wasn't.
While I have the same feeling about Firefox, it still lacks supporting some APIs, the Web Push API being the latest I missed that works properly on Chrome, enabling real push notifications.
You never say why. I install tools I use often globally, use NPX for ad-hoc tools. NPX invocation is slightly slower and its more to type. Never had any problems with either.
The why is that an upgrade of the globally-installed tool will apply to all projects using that tool. So if a breaking change in web-ext would require changes to your project, then you'll have to apply those changes to all your projects at once - unless they each have their own instance of it.
I see, I don't use any dependencies globally, but I do use global install for CLI tools I either invoke manually or use from scripts which I want to break if the tool CLI API changes so I can fix them and continue working on latest.
Global packages are harder to maintain. Let's say you installed foobar version 5 globally last year. This year, you're using a newer version of the foobar package that isn't backwards compatible. You install it globally, which replaces the old version 5. Now if you go back to the old project, your use of foobar is broken. Depending on the package, it might be fairly invasive/difficult to simply update.
For myself, I always install global-recommended packages as dev dependencies. It can be a little painful, but it also means there are no special install instructions, and it _just works_ (tm).
Thanks for posting this and for everyone else adding similar suggestions. I dove into web extension development earlier this year and couldn't find anything at all on automating testing. It was hard to Google testing for web extensions instead of web extensions used for testing. Couldn't find anything in mozilla's otherwise excellent docs either.
Last time I tried to test an extension on Firefox, with or without web-ext, two things of note:
1. yarn add web-ext fails with a bunch of errors on macOS 10.15, but npm install works. Not sure why.
2. The chrome.storage (or is it only storage.sync? can’t recall) API doesn’t work when the extension is loaded temporarily (since there’s no stable extension ID assigned or something), which is how `web-ext run` loads the extension, and the only way I could find to test the extension without submitting it to Mozilla for signing. Yeah I tweaked all the related settings in Firefox Developer Edition but couldn’t for the life of me figure out how to non-temporarily install my unsigned extension. So in the end I just gave up on testing the part of the extension that used chrome.storage, which was like 75% of the extension. A really hostile experience that will make sure I don’t port my extensions to Firefox in the future.
I think it's storage.sync. I get a warning about it too, but just ignored it so far. I think it's just the actual sync that doesn't work (settings still get set and loaded locally).
Okay, I pulled out the code and ran it on Firefox again to jog my memory. This is the error when doing anything with chrome.storage.sync:
Error: The storage API will not work with a temporary addon ID. Please add an explicit addon ID to your manifest. For more information see https://bugzil.la/1323228.
It's an error, not a warning, and set/get definitely don't work.
If I replace all storage.sync invocations with storage.local then it's okay, not error/warning, and setting/getting seems to work.
So the problem is limited to storage.sync, but it's not just a warning.
Edit: now that I googled the problem again, it seems adding an explicit addon ID according to https://extensionworkshop.com/documentation/develop/extensio... should work. I don't recall what I did back then, but I definitely did quite a few things to no avail.
Hmm I checked and I also have this bit of code I added a while ago to the manifest for non-release builds [0]: browser_specific_settings = {'gecko': {'id': 'promnesia@karlicoss.github.com'} }
Maybe this is what makes it just a warning (still not sure why it warns!).
Yeah I noticed that's the answer when I googled the error just now. Not sure why I didn't see it or it somehow didn't work at that time, the information should have been available (I encountered the problem late last year).
It's certainly misleading that the error message links to a bug, at least giving the impression that it is a bug, rather than a guide.
That said, IMO the underlying issue that Firefox doesn't allow you to just install an extension from a source directory like Chrome/Chromium does is much worse.
I read this before but I never encountered it before. Sync Storage works just fine, you just need to add the gecko extension ID to the manifest as described by other comments.
Absolutely, I'm using it to build an extension both for Chrome and Firefox [0].
Perhaps the only Firefox-specific thing is 'sign' command which signs for addonz.mozilla.org
This is a lovely tool, you can also implement automated builds and deploys using Github Actions to drive web-ext.
Chrome is pushing for manifest v3 and not seeking buy-in from the other web extension standard bearers. Also the new Firefox Mobile has incredibly spotty support for the API. Given these recent events, I worry that the cross-browser nature of this tool will be lost in time. And web extension development in general may be entering a dark age.
To be clear: Chrome was never part of any WebExtension standard. They do their own thing and WebExtension browsers decide which (if any) changes they want to support.
I hit this yesterday and I was very annoyed by it.
- The npm install fails on Windows if you don't have Visual Studio 2017+ installed. How is this acceptable for a utility that will mostly do some simple text-mangling?
- Mozilla is the birthplace of Rust. Why do I have to install Node to get a pretty simple utility like this? This should be a basic Rust executable you can just drop anywhere, no installation required.
- the very first line of `npm install web-ext` is a warning that some library is obsolete and should not be used. It's promptly followed by tons of similar ones. Again, how is this acceptable in 2020 for something so basic?
In the end I just dropped it.
Web-ext is not doing machine-learning billion-pageview-crunching rocket-launching stuff. It's a utility to roll up a few text files. The fact that it was built with Node seems yet another sign that Mozilla is dominated by SFBA cargo-cultism.
If you call communication with two different browsers (at least), validating source code, signing code and packing it up "simple text-mangling", I understand you're a bit frustrated. But I'm quite sure many see those features as a bit more than that, hence it is quite a popular tool to use in conjunction with browser extensions.
> Why do I have to install Node
Because web developers who do JavaScript for a living find it easier to write JavaScript to support their developer tools. Not a huge surprise here. I'm sure if you find the time to write the "simple text-mangling" in Rust, support it and maintain it, people would be more than happy to use it. But why rewrite something that works well enough for the intended users?
Speaking of cargo-cultism, you seem to have a bit of that stench on yourself as well, where suddenly every utility "should of course" be written in Rust, or otherwise be rewritten in Rust if they are not doing it yet.
Programmers will scratch their own itch with the languages that are familiar to them. Of course web extension dev tools will be written in languages and platforms that are the closest to the web ecosystem, which today is JavaScript.
> communication with two different browsers (at least), validating source code, signing code and packing it up
... is not something that requires a massive engine like Node. It just isn't.
> Because web developers who do JavaScript for a living find it easier to write JavaScript
This is an argument I can accept from a random free-time-opensource developer, not from a well-funded behemoth like Mozilla. An org that big should pay attention to what their objectives are, not what they feel like hacking together on any given day. How can they not see that making this sort of tool significantly burdensome to install on 90% of desktops is bound to limit its impact?
> suddenly every utility "should of course" be written in Rust
No. Write it in Go if you prefer. Write it in brainfuck, I don't care. What I care about, as a user, is that I can just get a single executable I can run on my machine. I care about usability, that's all I care about. How can it be acceptable for a tool like web-ext to have a setup story that is "figure out how to install npm; npm install web-ext and see it fail; figure out how to install Visual Studio (will it even work with the free version? I hope so); re-do npm install web-ext, ignoring a bunch of warnings about everything being horribly insecure and unmaintained"...? And then they have the gall to say in their copy that "you only need a text editor", just before pushing this crap. I mentioned Rust only because it's terrible optics that its very home doesn't dogfood it. Again, not rocket science to notice, at organizational level.
As a fervent Firefox advocate, this is the sort of thing that really riles me up.
I think in your rage against nodejs and/or Mozilla, you forget the target audience of this tool. The tool is written and provided for and by web developers who write browser extensions. The extensions themselves are written in HTML, CSS and JavaScript and the web developers who do write extensions, unless they are first time web developers, for most parts have nodejs already installed on their machine. For them, installing and using web-ext is as easy as it is for you to pull down a binary and putting in $PATH, or installing a tool via your package manager.
I maybe wouldn't have written web-ext in js with nodejs myself, but I do understand why others would make the choice to do so.
Although I agree that the whole nodejs/npm ecosystem is just a insecure clusterfuck waiting to be properly exploited at this point. About the Mozilla objectives, I don't think they even know them themselves at this point, even less so around 2015 when this tool first appeared.
I understand, but the reality is that Chrome's own experience to do this sort of thing is still miles ahead. It's literally trivial to build a Chrome extension. It's a big part of Chrome's success: people who used to struggle to build FF extensions when it was about XUL and RDF, when Chrome arrived could quickly bang together something that directly improved their life. Google understood that their audience was anyone using a browser, not just this or that subset of markup fanatics.
One of the pros of the Quantum switch was that building FF extensions became as easy as Chrome. Reintroducing complexity via the tooling is just self-harm.
I guess you are thinking this tool is required because you are coming from Google Chrome extension development where you need a compiler tool to create CRX files. This is not the case for Firefox extension development. It uses plain ZIP files.
You do not need this or any command-line tool to create Firefox extensions. You can create and publish an extension entirely with Notepad, Firefox, and the built in ZIP functionality of Windows Explorer if you want.
> ... is not something that requires a massive engine like Node. It just isn't.
How is asking for a Node install for a Javascript developer a problem?
My non-programmer wife recently started doing some Youtube tutorials to learn Javascript as her first coding experience and almost every single one has step 1 as "Install Node". Installing Nodejs is literally Javascript 101.
Also "Massive"? The Nodejs installer for Windows is 27MB (and requires like 4 clicks to install). On Linux, its available via the native installers and is a 1-click install.
> It's like asking people who want to learn Python: step 1, install Django. Or for Java: step 1, install Spring.
But Node is just a JavaScript runtime, like Python or Java. Of course, you don't need Node to run JavaScript in browser as it is built-in in the browser, but the built-in JavaScript engine doesn't allow you to easily use it externally.
> A simple browser extension doesn't need Node. It just doesn't. The browser itself already packs everything the extension needs.
You don't need to use it, as web-ext is just a extra tool to make it do some automation. You can just create some files and use Firefox to load it manually.
> And I could go on - why would a JS runtime/framework need Visual Studio, at all?
Because it uses native addon which is not written in JavaScript, so it need to be compiled when installing. Since Windows doesn't come with a compiler by default, you need to install it. It is more simpler to install it in Linux.
BTW, if you don't want a full visual studio to use native addon in Node.js, you can use https://www.npmjs.com/package/windows-build-tools instead, which provides tools you needed to compile things on Windows.
I'm not sure where you're coming from, but it's evident you haven't done JS development with nodejs, so let me give you the full picture here. nodejs is not a framework like Django or Spring. nodejs is a runtime for JS, just like Firefox and Chrome could be considered a runtime for JS (kind of, simplifying for you here). In fact, Chrome runs JS via V8, which is what nodejs is using too!
It's more correct to say "If you want to learn Python, you need to install a Python runtime", which for me makes a lot of sense. Of course I need somewhere to run Python if I want to learn Python. Same with JS, you need some sort of runtime, either the browser or something like nodejs. Many people go the nodejs route, as you'll end up probably needing or wanting tools from the nodejs ecosystem anyways, but some of us got started way before nodejs was even a thing, and some still do, nothing wrong with that.
> A simple browser extension doesn't need Node. It just doesn't. The browser itself already packs everything the extension needs.
Yeah, this is absolutely true today, for both Firefox and Chrome. In fact, the browser extensions we develop don't even have access to anything nodejs! This tool (web-ext) is simply a tool for making the developer experience better. You're in no way required to use it. You can simply create your files and manually zip things up, sign it and publish. Although it gets a bit easier with web-ext.
How hard is it to understand that Node.js is a JavaScript runtime with access to the filesystem?
I don’t understand most of your complaints. Web-ext does not need Visual Studio, it installs just fine on macOS. You should open an issue if you can’t install it on Windows.
Also deprecations happen frequently on npm so, while they’re annoying during instal, they’re not really a big deal, modules still work.
I have a few web extensions I wrote in order to customize a few web sites (automate tasks, alter display, etc). After a Firefox update, they were not allowed anymore, because they're not signed. The extensions page cannot load local extensions. Then I discovered the secret debug-extensions page of Firefox where I could load them.
Unfortunately, Firefox removes local extension when it closes. I had the choice between loading each local extension after launching a new Firefox, which mean a dozen of clicks, or installing web-ext in order to sign my extensions, and sign them again after each change (no idea if there were extra actions needed in the process, like manual reload). I opted for a much simple option: with Chromium-based browsers, you can enable the extension-developer mode, and then you're allowed to load local extensions from the normal extensions page. Extensions are kept across restarts.
If that ever changes i'll look into making my own Firefox binaries or whatever that have this check removed.
This updates frequently since it is basically Firefox beta (though in practice i never had any issue). Note that this has telemetry enabled by default so you may want to disable it via the options.
Unbranded stable: https://wiki.mozilla.org/Add-ons/Extension_Signing#Unbranded...
The unbranded stable isn't updated automatically so you'll need to check for new versions yourself (shouldn't be too hard to automate it with a python script or whatever that runs via cronjob or windows task scheduler and notifies you for new versions).
There isn't even a manual review gate for AMO releases after the first one (but it can happen after that fact).
I find Mozilla's policies friendlier than Google's but this is the first I've heard of "extension developer mode" - will have to look into that as my extension is cross browser.
https://extensionworkshop.com/documentation/publish/signing-...
The way I do it now is to package the extension as zip (no webext needed) with a custom manifest, which can be installed by setting xpinstall.signatures.required to false in the about:config page.
On the manifest side, you just need to include this snippet:
about:config xpinstall.signatures.required -> false
about:addons -> install xpiIt’s game changing.
https://github.com/binaryage/chromex is a good starting point if you're curious.
The downside of this is that it means no HMR support whatsoever.
The first time I tested my extension on Firefox after developing it one Chrome for months it worked the first time. I was so shocked how seamless it was I actually thought something must be really wrong, it wasn't.
[1] https://github.com/webextension-toolbox/webextension-toolbox
Please don't install npm packages globally. Use npx.
You can `npm install web-ext`, then run it with `npx web-ext arg1 arg2`.
Or just run `npx web-ext arg1 arg2` without installing, npx will install it first (if the package name matches the command).
So in the 'for your project' section, if you want to run without setting stuff up,
Just… update your global packages occasionally too. I use `npx npm-check -u -g`
For myself, I always install global-recommended packages as dev dependencies. It can be a little painful, but it also means there are no special install instructions, and it _just works_ (tm).
Off-topic: didn't Google recently announce they were using transformers for almost all English language queries?
I tried "testing for web extensions" in Google and got:
FAIL - 8 Best Chrome Extensions for QA Testing (featured result)
OK - Testing your web extension with integration tests
OK - How to test web extensions?
So the featured result was bad but results one and two were good.
1. yarn add web-ext fails with a bunch of errors on macOS 10.15, but npm install works. Not sure why.
2. The chrome.storage (or is it only storage.sync? can’t recall) API doesn’t work when the extension is loaded temporarily (since there’s no stable extension ID assigned or something), which is how `web-ext run` loads the extension, and the only way I could find to test the extension without submitting it to Mozilla for signing. Yeah I tweaked all the related settings in Firefox Developer Edition but couldn’t for the life of me figure out how to non-temporarily install my unsigned extension. So in the end I just gave up on testing the part of the extension that used chrome.storage, which was like 75% of the extension. A really hostile experience that will make sure I don’t port my extensions to Firefox in the future.
If I replace all storage.sync invocations with storage.local then it's okay, not error/warning, and setting/getting seems to work.
So the problem is limited to storage.sync, but it's not just a warning.
Edit: now that I googled the problem again, it seems adding an explicit addon ID according to https://extensionworkshop.com/documentation/develop/extensio... should work. I don't recall what I did back then, but I definitely did quite a few things to no avail.
[0] https://github.com/karlicoss/promnesia/blob/b9e59262b2fc51ef...
Definitely agree that the docs could be improved on web extension development & testing in general, I often feel the whole ecosystem is a bit hostile.
Yeah I noticed that's the answer when I googled the error just now. Not sure why I didn't see it or it somehow didn't work at that time, the information should have been available (I encountered the problem late last year).
It's certainly misleading that the error message links to a bug, at least giving the impression that it is a bug, rather than a guide.
That said, IMO the underlying issue that Firefox doesn't allow you to just install an extension from a source directory like Chrome/Chromium does is much worse.
Does anybody know how far it is from that aim? Is it useful at all if you're trying to build Chrome or Safari or all-3 webextensions?
[0] https://github.com/karlicoss/promnesia/blob/master/extension...
Chrome is pushing for manifest v3 and not seeking buy-in from the other web extension standard bearers. Also the new Firefox Mobile has incredibly spotty support for the API. Given these recent events, I worry that the cross-browser nature of this tool will be lost in time. And web extension development in general may be entering a dark age.
Was it ever not in a dark age? The overlap between FF and Chrome extension tech has actually existed for what, two years or so...?
- The npm install fails on Windows if you don't have Visual Studio 2017+ installed. How is this acceptable for a utility that will mostly do some simple text-mangling?
- Mozilla is the birthplace of Rust. Why do I have to install Node to get a pretty simple utility like this? This should be a basic Rust executable you can just drop anywhere, no installation required.
- the very first line of `npm install web-ext` is a warning that some library is obsolete and should not be used. It's promptly followed by tons of similar ones. Again, how is this acceptable in 2020 for something so basic?
In the end I just dropped it.
Web-ext is not doing machine-learning billion-pageview-crunching rocket-launching stuff. It's a utility to roll up a few text files. The fact that it was built with Node seems yet another sign that Mozilla is dominated by SFBA cargo-cultism.
If you call communication with two different browsers (at least), validating source code, signing code and packing it up "simple text-mangling", I understand you're a bit frustrated. But I'm quite sure many see those features as a bit more than that, hence it is quite a popular tool to use in conjunction with browser extensions.
> Why do I have to install Node
Because web developers who do JavaScript for a living find it easier to write JavaScript to support their developer tools. Not a huge surprise here. I'm sure if you find the time to write the "simple text-mangling" in Rust, support it and maintain it, people would be more than happy to use it. But why rewrite something that works well enough for the intended users?
Speaking of cargo-cultism, you seem to have a bit of that stench on yourself as well, where suddenly every utility "should of course" be written in Rust, or otherwise be rewritten in Rust if they are not doing it yet.
Programmers will scratch their own itch with the languages that are familiar to them. Of course web extension dev tools will be written in languages and platforms that are the closest to the web ecosystem, which today is JavaScript.
... is not something that requires a massive engine like Node. It just isn't.
> Because web developers who do JavaScript for a living find it easier to write JavaScript
This is an argument I can accept from a random free-time-opensource developer, not from a well-funded behemoth like Mozilla. An org that big should pay attention to what their objectives are, not what they feel like hacking together on any given day. How can they not see that making this sort of tool significantly burdensome to install on 90% of desktops is bound to limit its impact?
> suddenly every utility "should of course" be written in Rust
No. Write it in Go if you prefer. Write it in brainfuck, I don't care. What I care about, as a user, is that I can just get a single executable I can run on my machine. I care about usability, that's all I care about. How can it be acceptable for a tool like web-ext to have a setup story that is "figure out how to install npm; npm install web-ext and see it fail; figure out how to install Visual Studio (will it even work with the free version? I hope so); re-do npm install web-ext, ignoring a bunch of warnings about everything being horribly insecure and unmaintained"...? And then they have the gall to say in their copy that "you only need a text editor", just before pushing this crap. I mentioned Rust only because it's terrible optics that its very home doesn't dogfood it. Again, not rocket science to notice, at organizational level.
As a fervent Firefox advocate, this is the sort of thing that really riles me up.
I maybe wouldn't have written web-ext in js with nodejs myself, but I do understand why others would make the choice to do so.
Although I agree that the whole nodejs/npm ecosystem is just a insecure clusterfuck waiting to be properly exploited at this point. About the Mozilla objectives, I don't think they even know them themselves at this point, even less so around 2015 when this tool first appeared.
I understand, but the reality is that Chrome's own experience to do this sort of thing is still miles ahead. It's literally trivial to build a Chrome extension. It's a big part of Chrome's success: people who used to struggle to build FF extensions when it was about XUL and RDF, when Chrome arrived could quickly bang together something that directly improved their life. Google understood that their audience was anyone using a browser, not just this or that subset of markup fanatics.
One of the pros of the Quantum switch was that building FF extensions became as easy as Chrome. Reintroducing complexity via the tooling is just self-harm.
You do not need this or any command-line tool to create Firefox extensions. You can create and publish an extension entirely with Notepad, Firefox, and the built in ZIP functionality of Windows Explorer if you want.
How is asking for a Node install for a Javascript developer a problem?
My non-programmer wife recently started doing some Youtube tutorials to learn Javascript as her first coding experience and almost every single one has step 1 as "Install Node". Installing Nodejs is literally Javascript 101.
Also "Massive"? The Nodejs installer for Windows is 27MB (and requires like 4 clicks to install). On Linux, its available via the native installers and is a 1-click install.
It's like asking people who want to learn Python: step 1, install Django. Or for Java: step 1, install Spring.
A simple browser extension doesn't need Node. It just doesn't. The browser itself already packs everything the extension needs.
And I could go on - why would a JS runtime/framework need Visual Studio, at all?
But Node is just a JavaScript runtime, like Python or Java. Of course, you don't need Node to run JavaScript in browser as it is built-in in the browser, but the built-in JavaScript engine doesn't allow you to easily use it externally.
> A simple browser extension doesn't need Node. It just doesn't. The browser itself already packs everything the extension needs.
You don't need to use it, as web-ext is just a extra tool to make it do some automation. You can just create some files and use Firefox to load it manually.
> And I could go on - why would a JS runtime/framework need Visual Studio, at all?
Because it uses native addon which is not written in JavaScript, so it need to be compiled when installing. Since Windows doesn't come with a compiler by default, you need to install it. It is more simpler to install it in Linux.
BTW, if you don't want a full visual studio to use native addon in Node.js, you can use https://www.npmjs.com/package/windows-build-tools instead, which provides tools you needed to compile things on Windows.
It's more correct to say "If you want to learn Python, you need to install a Python runtime", which for me makes a lot of sense. Of course I need somewhere to run Python if I want to learn Python. Same with JS, you need some sort of runtime, either the browser or something like nodejs. Many people go the nodejs route, as you'll end up probably needing or wanting tools from the nodejs ecosystem anyways, but some of us got started way before nodejs was even a thing, and some still do, nothing wrong with that.
> A simple browser extension doesn't need Node. It just doesn't. The browser itself already packs everything the extension needs.
Yeah, this is absolutely true today, for both Firefox and Chrome. In fact, the browser extensions we develop don't even have access to anything nodejs! This tool (web-ext) is simply a tool for making the developer experience better. You're in no way required to use it. You can simply create your files and manually zip things up, sign it and publish. Although it gets a bit easier with web-ext.
I don’t understand most of your complaints. Web-ext does not need Visual Studio, it installs just fine on macOS. You should open an issue if you can’t install it on Windows.
Also deprecations happen frequently on npm so, while they’re annoying during instal, they’re not really a big deal, modules still work.