Sven Slootweg (soft-deprecated) @joepie91@pixie.town

@rune Browserify is really neat in general, the normal way you use it is to just use the (CommonJS) module system in your code and point Browserify at it, and it will produce a bundle including all deps, just one simple invocation without needing a config file.

The standalone mode is a slightly different mode where instead of producing a bundle of your codebase that it *runs* upon loading, it produces a bundle that *assigns the export globally*, usually so that non-Browserified/module-system code can use it externally. Often used for either in-progress migration to module-based code, or quick hacks like this one.

And in standalone mode you can also just point it at some installed module instead of your own code as the entry point, and it'll happily generate a global export for it :)

(Definitely would recommend non-standalone mode for anything serious though, having a module system is *so much nicer* than juggling globals and dealing with scope pollution)

@rune https://gist.github.com/joepie91/174969cba90b0bcab91b8e4d47d8569f -- this *should* be a 'standalone build' of the package that exposes whatever it exports as the VanillaTree global when loaded via script tag

@sys64738@hellsite.site @AgathaSorceress@eldritch.cafe No it's when you're a bank and you stop sending paper statements to your customers, and instead you "digitize" them directly after printing and then throw away the print, only letting the customer access the scanned PDFs

@waweic@chaos.social @schratze And that may superficially sound like an irrelevant distinction, but what it comes down to in practice is that you can build on other people's work without *also* being forced to buy into their specific distro policies (at the cost of system fragility if you deviate in any way)

@Dee @maia Statute of limitations: 1 (one) reboot

@waweic@chaos.social @schratze Yeah but a low barrier to entry is still *a* barrier to entry, and there are lots of reasons why it might not be practical to get something in there. Maybe there are licensing issues, maybe it's internal software, maybe you and the people managing that repo don't get along, maybe it's something of your own that *you* want to package but not suggest to anybody else that it is ready for use yet, etc.

Nix/Guix solve this on a much more fundamental level, by pretty much removing the concept of a "repository" as some specially-privileged thing, and instead just defining your system as a collection of configuration, some of which happens to describe how to build packages.

It doesn't care whether that 'build configuration' comes from the nixpkgs maintainers (in the case of Nix), or some internal repo, or is even defined inline in your system configuration - it's all just code that evaluates to a pile of packages, and with transparent opportunistic binary substitution.

In other words: nixpkgs, which is conceptually more or less equivalent to an "official" repository for Nix, uses the *exact same tools* that you use in constructing your system configuration, there is no privileged anything involved.

And you don't need to "build your packages against dependencies in nixpkgs" either (treating nixpkgs as strictly authorative and even third-party things have to de facto play by its rules); because of how the evaluation works, dependencies are just references to other packages, and version conflicts don't exist, so you can totally use dependencies from wherever.

So in other words: instead of having a model where there's one authorative source controlling the system and you just have to hope it leaves room for your requirements, you get an "authority-agnostic" system where you don't need *anybody's* permission to package something with the same degree of integration and reliability as in nixpkgs.

@schratze Honestly this is one of the biggest issues I have with most package management systems - there's "distro maintainers packaging software" and then there's "third-party packages" and there's usually a *huge* wall between them in terms of tooling, and quality of integration, and so on, where the moment you use the latter, reliability goes to shit.

And then flatpaks/appimages/snaps/etc. try to "fix" that by introducing a new packaging format that basically just vendors all the dependencies, and is *still* a completely separate system from the *actual* system package manager, so the wall is still there...

And honestly Nix/Guix are the only ones I've seen that have a convincing answer to this problem by erasing the wall between those two categories on a structural level, and I *hate* that this model is not more widely adopted by other distros and package managers. I don't even care if it's Nix/Guix themselves being used. But the solution is just left on the table...

Grumble

@schratze Ah I know *exactly* where this page is from