Kind of an interesting read. First thoughts, I generally think this is bad practice. I mean, for one thing this guarantees you need an Internet connection to r

Kind of an interesting read. First thoughts, I generally think this is bad practice. I mean, for one thing this guarantees you need an Internet connection to run your Node script, which seems pretty problematic. I'm also reading some really questionable security justifications from people on the issue tracker about why dynamic imports are actually fine and just as secure as importing packages from NPM. There are security improvements that could be made to NPM, particularly around package search, and NPM has suffered from people replacing existing package versions (although I think they're clamping down on this more now). But there is a really fundamental difference between taking that risk once during installation and taking that risk multiple times at runtime. Additionally, in regards to some of the comments saying that installing code directly from the source ("express.com" vs "npm.com") ignores the fact that this is already kind of possible with npm dependencies and promoting that method wouldn't have any of the other problems. ---- HOWEVER: You read further and there are actually some really interesting security risk mitigations being proposed that don't just boil down to saying "all imports are dangerous, why not do them here too." "Scopes" (which I was not aware was a concept that Node had any support for) are the idea that packages in a scope or a domain can't access any dependencies outside of them. Additionally, people are talking about mirroring Deno's system where these get cached locally and not re-fetched later, which is kind of similar to npm's system and reduces some risk. So you can load a module from HTTPS and in theory it only gets fetched once and it can't access the file system, cool. Additionally, `node_modules` dependencies can't use them, which is cool, means that it's less likely a random dependency starts doing this behind your back. ---- HOWEVER: Prototype pollution is still a thing, passing objects around across closures is still a thing, and as far as I know this is a big part of why it's difficult to sandbox Javascript modules. Scopes are really interesting, but I can't find a lot of information about them online, and their name conflicts with npm scopes, which are a different thing. And I can't find any info suggesting they've solved the bigger problems of sandboxing modules. And there's still the elephant in the room, which is that all of those security measures are stuff that could be done in a more general way that applies to normal modules? I'm not sure why I would only want scopes for HTTPS imports, assuming they even work securely for HTTPS imports in the first place, which I wish I could find more information about. It's cool that a module gets fetched once at runtime and not later, but that still means I need an Internet connection the first time the Node script runs. And it seems like "tell me what dependencies you need and I'll fetch them" is a good candidate for an install step, which Node has. I'm not totally against the idea, I can in theory think of situations where you might want to install something at runtime without knowing ahead of time what it is. But that's also really dangerous to do, and doesn't really fit with the caching model that is being proposed. ---- So I still feel pretty doubtful that this is a good feature to add, and it seems really dangerous at first glance, but maybe there are other use-cases that I don't understand or maybe there's something to scopes that I don't get. I will say that if I actually trusted the security of scopes as a way of sandboxing individual modules, then at that point I feel a lot better about dangerous imports in general. But I can't find any info on scopes, and as far as I know, systems like Deno gave up on this because it was really hard, and I also vaguely feel like effective module-level sandboxing in Node would be much bigger news than any import feature. But :shrug:, I could be missing something. This is based on only a quick read through the entire thread and a tiny bit of extra searching/reading the commit docs.