Comment by Too
2 years ago
Reproducible builds and open source sounds like a good thing.
I wouldn’t expect the reviewers to deal with every add-ons bespoke snowflake build. Even less so if it requires access to a private module. Mozilla should provide a baseline of how a build is intended to be done, then extensions just have to follow this template. Though yes, you would expect them to have some familiarity with basic stuff like yarn and that the baseline supports a few of the most popular builders.
We use a relatively simple build. at the base of it, if you have node and npm, a complete build is as easy as
yarn npm login
yarn --immutable
yarn build
Personally - I don't really find it reasonable to place demands on build tooling for an external company.
I'm assuming you would also find it reasonable for Google to suddenly ship chromium with a requirement that you use "google-pack" for all js builds or they don't run it?
To be entirely blunt, what exactly do you think is going to change when we're already giving them bare JS? It's not like we're shipping a binary blob here, we're literally handing them a zip file with perfectly fine & inspectable javascript inside it.
Further, do you realistically believe that a single low grade QA/Support engineer who can't even install the correct tooling is going to catch malware?
Because I read their matrix chats and I can fucking promise they aren't catching the malware all that fast....
> I don't really find it reasonable to place demands on build tooling for an external company.
I'm not sure I agree, plenty of OS distributions do this. If you want to distribute on Arch in the official AUR you're going to need a PKGBUILD file. The difference though is they make it very easy to integrate custom distribution channels where you can build the package however you want, and I would really love to see browsers move more in that direction. Requiring centrally managed signatures from a corporation to install extensions in a purportedly open and community-driven product is just absurd to me.
> I'm not sure I agree, plenty of OS distributions do this. If you want to distribute on Arch in the official AUR you're going to need a PKGBUILD file.
This is fine. This is actually also roughly in line with what you need for an extension (a manifest.json file).
What the poster here is proposing is rather this: You cannot build that PKGBUILD file using any tooling other than the standard. Ex - you want to script how that PKGBUILD file get made? Fuck off, not allowed.
That's a COMPLETELY different take. It's not dictating limitations on the output (which I find reasonable as a required integration between products) it's dictating limitations on how a company produces that output (I find this monopoly behavior, why should they get to tell me what tools or processes to use? My output is the SAME.).
Docker
It seems reasonable that they'd have a requirement there's a single file they'll run, maybe even with a predetermined name like ./build, and that's it.
The developer can then juggle all their dependencies and run make/yarn/npm/etc within that. It's really not different from having a CI build script.
And surely they should accommodate controlling the ENV of that build process as well?
Perhaps by doing things like setting NPM_TOKEN for the correct account?
Just like you would with CI?
... except they claim that's too hard.