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

@crumbcake That matches what I've seen, though paired with a crucial other trend that makes this possible in the first place: a broader move towards monolithic frameworks that reinvent their own wheels.

It used to be that modules had a single well-specified purpose, and it did that well, and even frameworks were generally designed to be highly interoperable. This eliminated whole classes of issues like month-long framework upgrade chores, library architecture incompatibilities, and bugs in utility functions (because everyone used the same well-tested ones).

However, since Node.js ended up in the startup hype cycle, that has been changing, with increasingly many do-it-all frameworks appearing (because those are really easy to market - large feature lists!), that barely interact or interoperate with the ecosystem at all, instead having their own buggy homegrown implementations of existing tools inlined into their codebase.

That does mean those frameworks are unlikely to run into issues interoperating with the existing ecosystem of CommonJS modules and can therefore afford to do ESM, but for all the wrong reasons...

@Scmbradley @schratze Responding to this seriously for a moment: I always put a lot of work into making sure my software works reliably. Sometimes that means not having certain features because they are impossible to implement reliably.

But what then happens, is that it fails to gain traction and adoption the way that shinier, less reliable options do, because on paper my thing has 'less features'. There are more factors that affect adoption, of course, but this is definitely a real issue.

And while adoption for the sake of adoption isn't useful, widespread adoption *is* usually how people learn of the existence of a thing. So the result is that I can't reach people who would have been interested in it.

And I feel like that's part of the problem here, not just for me - we need structures for distributing knowledge of tools and devices that may be obscure, but that are deliberately reliable, that don't rely on things just coincidentally landing at the feet of the right people, because that implicitly depends on it having mass market appeal.

Otherwise all the incentives are aligned to do the less reliable but more appealing thing.

@zens@merveilles.town I was providing a partial correction on a common misconception, with rationale and a boundary of where it applies, because this one often leads to people painting themselves into a corner and I would like to help prevent that.

I wasn't signing up for an adversarial argument that basically boils down to "I have no idea what you're doing but you definitely don't need X".

@zens@merveilles.town I have no idea what you're referring to there, to be honest, but I also don't feel like this is going to lead to a constructive discussion, to be honest.

You seem to have already decided that transitive dependencies are the wrong solution no matter what, and any attempt to engage with the question seems likely to just result in skipping over the nuance to try and find a way to argue that it's wrong anyway. I don't have the energy for that kind of adversarial discussion.

@affine@yourwalls.today Didn't get the weewoo here today :(

@crumbcake That holds true for (bundled) browser code; but crucially, not in environments with native support for modules, like Node.js, as there is no build step there.

Leading to a situation where everything seems to be 'fine' to people who only do browser-side code, but constant breakage in server environments of the same modules... 🥴

@zens@merveilles.town "Don't use transitive dependencies" is just a "you're holding it wrong" argument and not really useful; it doesn't recognize that there are very good reasons to do so, or provide any avenue for finding other solutions to those needs.

And yes, manifests exist. That's what I was referring to "just a manifest of the full dependency tree" - but that doesn't change anything about needing to do bundling, because you still need to *generate* that manifest, and "walking the dependency tree and building up a manifest of all the modules" is what bundling *is*; the output format (manifest or concatenated code) is just an artifact of that.