Longtime node.js developer... I don't think we need this, and I don't think it's a good idea to add. The feature is _strange._ Which we know because it's behin

Longtime node.js developer... I don't think we need this, and I don't think it's a good idea to add. The feature is _strange._ Which we know because it's behind a flag, i.e., it will have low utilization. It defies conventions—because the convention is to use a registry for packages. And it presents significant security concerns. (Which I don't really have to explain, as they're already cited as the reason to put it behind a flag.) Use of this feature seems like something you might see once in a career. (Indeed, I've seen a similar thing in another language employed only once... AND THERE WERE OTHER WAYS for that developer to have designed that system that would not have been so vulnerable.) When you see it, do you recognize what it is, understand and evaluate the risks it poses? Do you validate that the library sitting on the other side hasn't been taken over by a malicious actor? Do you validate that the library on the other side has up-to-date dependencies? If so, on what cadence do you do this, realistically? All the security tooling progress we've made (npm audit, etc.) seems shot in the foot by this. And I get that these concerns aren't dispositive on their own. I just don't see the argument on the other side that clearly. Is there some class of application that people really want to write in node that can't be written for lacking this? Do we really think this is a pattern that would be employed in well-made, secure codebases? I don't see the argument. Like I said, I've seen a feature like this used in another language. But I haven't seen it needed for any real application. I love me some good node ugly hacks. Still, the language features should be nudging us to write good software.