3 ms·

Evaluating these things at runtime is absurd. It was absurd when deno wanted to do it and it’s absurd now. People keep equating the threat model of npm and url

Evaluating these things at runtime is absurd. It was absurd when deno wanted to do it and it’s absurd now. People keep equating the threat model of npm and url imports, but with npm the untrusted code gets downloaded at build time, so tools like snyk can scan it and flag problems. Is snyk supposed to intercept the live download and patch files now? Are the policy integrity checks they mention in the PR allow or block lists? For example, if my malicious trojan module does a dynamic import, can it bypass a saved integrity check by adding a cache bust url parameter? Honestly, I don’t think the idea of URL imports is inherently bad. Go manages with them pretty reasonably. However, go only processes them at build time. My docker image from node might run today and break tomorrow because it’s allowed to change the remote code it runs day to day.

wperron 5y ago
If you actually read the (admittedly long) thread, it's pretty clear that those imports are not resolved at runtime, and Deno has never evaluated imports at runtime either. Dependencies get evaluated and downloaded prior to startup, very similar to Go in fact.
- CGamesPlay 5y ago
  I don't see that listed anywhere in the thread, so I'll ask here instead: Does prior to startup mean there's a separate build step, or are you saying it happens during the loading of the script. I'm pretty confident that the latter is what deno was doing, although I'm happy to be proven wrong. Are dynamic imports simply disallowed? Since it is impossible to download in advance a script to which you don't know the URL without running the program, they'd have to be, in order for your assertion to be true.
  - wperron 5y ago
    The whole conversation is a bit hard to follow, there was an issue initially, then this PR and then another Discussion that's linked somewhere in the PR. I'll let you go read those, I don't recall exactly what decisions were taken and what's the roadmap for this to become stable. Dynamic imports are... wild, to say the least. Unfortunately they will always be inherently harder to secure, and will most likely always be treated differently than static import statements. At least that was the consensus in Deno.
  - danShumway 5y ago
    ES imports on the web have a lot of restrictions around where they can be placed in code. Trying to pass a variable in for the path results in a syntax error. There are basically a lot of syntax requirements that make it basically impossible to do imports that aren't statically analyzable without the need to run the code. However, given that ES imports are basically trying as hard as possible to be explicitly defined static imports that can be analyzed ahead of time before code is run -- it prompts the question, why would you ever choose to use that system in a native environment where you could have have an explicit install step? ES Imports are trying very hard to imitate what Node already has, and I can't figure out what the advantage is of building an import system that imitates dynamic imports, but isn't dynamic. My understanding was that Deno went that direction just to make webpack bundling easier and to decrease the amount of new syntax. I felt like that was not great reasoning at the time, but I sort of get it. But note that when I look at Deno's docs[0], the first paragraph I see says: > One convention places all these dependent URLs into a local deps.ts file. Functionality is then exported out of deps.ts for use by local modules. > Continuing this convention, dev only dependencies can be kept in a dev_deps.ts file. It's almost like Deno is advising developers to put their dependencies in (just trying to come up with a random descriptive term off the top of my head) a package file. Next, wouldn't be it be great if that list of dependencies could also specify other things like a set of common scripts, or instructions on how to run the program if it's imported? There's potentially a really good concept embedded in those docs. Deno was made by smart people, and it was made by smart people who also created Node and are intimately familiar with it. So I don't want to be dismissive because I'm sure they had some reasons for this, but I don't understand why any of this exists or who it benefits, or why the syntax is exciting given that Deno itself seems to be immediately advising people not to use it directly. ---- [0]: https://deno.land/manual/examples/manage_dependencies https://deno.land/manual/examples/manage_dependencies
    - CGamesPlay 5y ago
      > ES imports on the web have a lot of restrictions around where they can be placed in code. Trying to pass a variable in for the path results in a syntax error. I'm referring to dynamic imports, which do not have any compunctions around dynamic strings being used to import modules. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#dynamic_imports https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

wperron 5y ago

If you actually read the (admittedly long) thread, it's pretty clear that those imports are not resolved at runtime, and Deno has never evaluated imports at runtime either. Dependencies get evaluated and downloaded prior to startup, very similar to Go in fact.

CGamesPlay 5y ago
I don't see that listed anywhere in the thread, so I'll ask here instead: Does prior to startup mean there's a separate build step, or are you saying it happens during the loading of the script. I'm pretty confident that the latter is what deno was doing, although I'm happy to be proven wrong. Are dynamic imports simply disallowed? Since it is impossible to download in advance a script to which you don't know the URL without running the program, they'd have to be, in order for your assertion to be true.
- wperron 5y ago
  The whole conversation is a bit hard to follow, there was an issue initially, then this PR and then another Discussion that's linked somewhere in the PR. I'll let you go read those, I don't recall exactly what decisions were taken and what's the roadmap for this to become stable. Dynamic imports are... wild, to say the least. Unfortunately they will always be inherently harder to secure, and will most likely always be treated differently than static import statements. At least that was the consensus in Deno.
- danShumway 5y ago
  ES imports on the web have a lot of restrictions around where they can be placed in code. Trying to pass a variable in for the path results in a syntax error. There are basically a lot of syntax requirements that make it basically impossible to do imports that aren't statically analyzable without the need to run the code. However, given that ES imports are basically trying as hard as possible to be explicitly defined static imports that can be analyzed ahead of time before code is run -- it prompts the question, why would you ever choose to use that system in a native environment where you could have have an explicit install step? ES Imports are trying very hard to imitate what Node already has, and I can't figure out what the advantage is of building an import system that imitates dynamic imports, but isn't dynamic. My understanding was that Deno went that direction just to make webpack bundling easier and to decrease the amount of new syntax. I felt like that was not great reasoning at the time, but I sort of get it. But note that when I look at Deno's docs[0], the first paragraph I see says: > One convention places all these dependent URLs into a local deps.ts file. Functionality is then exported out of deps.ts for use by local modules. > Continuing this convention, dev only dependencies can be kept in a dev_deps.ts file. It's almost like Deno is advising developers to put their dependencies in (just trying to come up with a random descriptive term off the top of my head) a package file. Next, wouldn't be it be great if that list of dependencies could also specify other things like a set of common scripts, or instructions on how to run the program if it's imported? There's potentially a really good concept embedded in those docs. Deno was made by smart people, and it was made by smart people who also created Node and are intimately familiar with it. So I don't want to be dismissive because I'm sure they had some reasons for this, but I don't understand why any of this exists or who it benefits, or why the syntax is exciting given that Deno itself seems to be immediately advising people not to use it directly. ---- [0]: https://deno.land/manual/examples/manage_dependencies https://deno.land/manual/examples/manage_dependencies
  - CGamesPlay 5y ago
    > ES imports on the web have a lot of restrictions around where they can be placed in code. Trying to pass a variable in for the path results in a syntax error. I'm referring to dynamic imports, which do not have any compunctions around dynamic strings being used to import modules. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#dynamic_imports https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...