Banned? Is that why you had to post this on a green text account? Because that sounds immature. If you really have so many repos it sounds annoying that there isn't room for team level experimentation.

It's not immature, it's pragmatic. You do have to weigh the benefits of being able to use non-standard tools vs the cost of having not being able to reuse the same tooling, linters, compilers, and what-not for all projects.

When you have a lot of projects to support, it's rare for the benefits to outweight the costs

> If you really have so many repos it sounds annoying that there isn't room for team level experimentation.

For what it's worth, I'll say that I can understand such top down governance: you'd have an easier time around moving across projects that you work on within the org, there'd be less risk of a low bus factor, BOM and documentation/onboarding might become easier.

Same as how there are Java or .NET shops out there, that might also focus on a particular runtime (e.g. JDK vendor) or tooling (an IDE, or a particular CI solution, even if it's Jenkins).

On the other hand, if the whole org would use MySQL but you'd have a use case for which PostgreSQL might be a better fit, or vice versa, it'd kind of suck to be in that particular situation.

It's probably the same story for Node/Deno/Bun, React/Vue/Angular or anything else out there.

No reason why that mandated option couldn't eventually be Bun, though, for better or worse.

Devil's advocate: Deno and Bun are not yet fully backwards compatible with Node. I myself have run into a _ton_ of pain trying to introduce Bun for my team.

This can become a big time sink on bigger teams. That time could be saved by just not allowing it until a full team initiative is agreed on.

Why do you have 1700 repos?

The wonders of JavaScript package dependencies, where basic CS stuff is a function exported as a package.

Probably an agency environment, or a enterprise environment that insists on having private mirrors of all 3rd party code.