Mozilla/web-ext: A command line tool to help build, run, and test web extensions(github.com)
github.com
Mozilla/web-ext: A command line tool to help build, run, and test web extensions
https://github.com/mozilla/web-ext
64 comments
You can still use firefox autoconfig scripts to do a lot of things that they locked down(like using old XUL apis) https://support.mozilla.org/en-US/kb/customizing-firefox-usi...
If you only need to tweak websites, using a userscript manager is much more easier: https://addons.mozilla.org/en-US/android/addon/violentmonkey...
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:
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:
"browser_specific_settings": {
"gecko": {
"id": "[email protected]"
}
}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)
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.
If that ever changes i'll look into making my own Firefox binaries or whatever that have this check removed.
Unbranded stable (and beta) builds also allows disabling the signature check. There are plenty of options, just not in the official stable builds.
What is up with this "Developer edition", "Unbranded stable", and God knows what else?
Developer edition: https://www.mozilla.org/en-US/firefox/developer/
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).
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).
And the long-term support (ESR) version as well, if I remember correctly.
That makes things even easier then :-P
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.
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.
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.
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.
At least until 82 I (have to try if it still works), I used:
about:config xpinstall.signatures.required -> false
about:config xpinstall.signatures.required -> false
zip -0 mywebext.xpi manifest.json *.js *.png *.html
That worked for me only after including this snippet on the manifest:
"browser_specific_settings": {
"gecko": {
"id": "[email protected]"
}
}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.
https://extensionworkshop.com/documentation/publish/signing-...
https://extensionworkshop.com/documentation/publish/signing-...
What is the signature good for if they hand it out without review? Might as well get rid of the requirement.
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’s game changing.
It’s game changing.
Heh, once you want even tighter feedback than just reloading the extension itself, try out developing a extension with ClojureScript ;)
https://github.com/binaryage/chromex is a good starting point if you're curious.
https://github.com/binaryage/chromex is a good starting point if you're curious.
> 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
It’s unrelated to the build, it works even if you edit files directly.
The downside of this is that it means no HMR support whatsoever.
The downside of this is that it means no HMR support whatsoever.
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.
Me too, in fact it has a —preserve-changes flag (or something like that) that combined with the -p flag let’s you have a profile just for development.
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.
[1] https://github.com/webextension-toolbox/webextension-toolbox
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
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.
> npm install --global web-ext
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,
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,
npx web-ext run --source-dir ./extension-dist/Yes and no. I love npx but if you’re launching a package more often than once a week you should probably install it because it’s just faster to do so.
Just… update your global packages occasionally too. I use `npx npm-check -u -g`
Just… update your global packages occasionally too. I use `npx npm-check -u -g`
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).
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.
> It was hard to Google testing for web extensions instead of web extensions used for testing.
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.
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.
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.
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:
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.
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.
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': '[email protected]'} }
Maybe this is what makes it just a warning (still not sure why it warns!).
[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.
[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.
> browser_specific_settings
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.
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.
[deleted]
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.
I note this 'aims' to support browser extensions in a cross-platform way, but it's primarily focused on Firefox.
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?
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?
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
[0] https://github.com/karlicoss/promnesia/blob/master/extension...
[0] https://github.com/karlicoss/promnesia/blob/master/extension...
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.
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.
> 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...?
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...?
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.
There will always be Greasemonkey & co.
For more information and tools, see
https://youtu.be/6jgBM8twUIQ
https://github.com/mozilla/webextension-polyfill
I wonder why they chose to go with flow over typescript.
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.
- 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.
> mostly do some simple text-mangling
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.
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.
... 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 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.
> you forget the target audience of this tool.
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 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.
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.
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.
The fact that people don't see this as troubling, is sad in itself.
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?
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?
> 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.
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.
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.
[deleted]
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 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.