4 ms·

Importing from HTTP is a bad idea on so many different levels and for so many different reasons (security, immutability, sec compliance, project integrity… the

Importing from HTTP is a bad idea on so many different levels and for so many different reasons (security, immutability, sec compliance, project integrity… the list just goes on and on). We’ve been there (PHP remote includes) and it’s as bad as it can get. Please don’t say HTTP imports are a good idea. Please.

nkozyra 5y ago
I think you're maybe confusing what's effectively a namespace and point in time install with a dynamic import. Otherwise there's no difference between http "imports" and any dependency management system (which ultimately import from some http endpoint)
- develatio 5y ago
  If we're talking about https://deno.land/manual/linking_to_external_code https://deno.land/manual/linking_to_external_code , then I stand to what I said.
  - nkozyra 5y ago
    But again - and this is mentioned in the page, nothing here is unique to Deno. It semantically feels different, but is in practice no different than most dependency management systems.
    - develatio 5y ago
      It feels broken, because it's a bad idea, per the design itself. Basically, you're ("you" as in figuratively speaking) smashing the functionality of a package manager into the interpreter. I'm not convinced at all that making a single tool do more and more stuff is a good idea, but let's keep on. Then, you're writing URLs (for the libraries you're importing) all over the code (which is just bad). Deno's solution (from the link in my prev reply) is to just put all the URLs in a single file (so, basically a "packages.json", but now inside your code, ¿because that's somehow a good idea?). Then there's the entire thing about replacing NPMJS, which has full-time engineers working on security, maintenance, etc... with a bunch of different servers, maybe maintained, maybe not, by random people. Then there's the entire "but how can I be sure that the code didn't change?" thing, to which Deno suggests to use a "--lock command flag". This sounds like "npm.lock / yarn.lock". And finally, there's the availability concern ("what happens if any of these servers goes down?"), which Deno just dismisses by saying that this can happen to any server. And while that is technically true, pulling all your dependencies from a single place, instead of N different places, reduces the points of failure to 1 (instead of N). So, this entire "import directly from URLs" sounds just like a package manager with different steps, without providing anything new, without fixing any specific problems with package managers, and introducing new problems (which are in fact old problem, because as I said, we've been there already when PHP thought remote includes were a good idea).
      - nkozyra 5y ago
        The lock concept isn't at all unique to npm/yarn because you need some form of checksum/hash verification. Even if you trust your source that's unlikely to be part of a repo and doesn't guarantee the next developer can trust what they get. Availability is a concern, but again if you have it once you have some way of including it in the project. I think there's a security nightmare with anything that's going to end up in browser at some point. It's such an exploitable surface. And PHP was not a thoughtfully designed language, but the bad part wasn't the fact that remote includes were possible but that there was no attempt at sandboxing or security built into the functionality. I'm not sold on Deno for what it's worth. I do agree with you on interpreter not really needing to be in charge of package management, but compilers do it all the time and most typescript ends up getting compiled or transpiled anyway.
    - forty 5y ago
      The difference is that you mix your code and package management. I'm not sure why the code would need to know where you obtained the dependency. This is package manager business. Whether you get the dependency from your git repo, from a centralized package repository or from a random url had nothing to do in the code.
      - ronsor 5y ago
        > The difference is that you mix your code and package management. To an extent, Go does the same thing, even though the modules slightly changed that.
        nkozyra 5y ago
        I think this is a nit - most modern compiled languages do this but at the compiler level.
brundolf 5y ago
The thing is, somebody could (and maybe should!) launch a curated, versioned, audited package registry that just happens to operate through URLs. The URLs are just the mechanism; they make Deno less opinionated about where it gets its packages, but they don’t preclude something more managed and featureful like NPM.

nkozyra 5y ago

I think you're maybe confusing what's effectively a namespace and point in time install with a dynamic import. Otherwise there's no difference between http "imports" and any dependency management system (which ultimately import from some http endpoint)

develatio 5y ago
If we're talking about https://deno.land/manual/linking_to_external_code https://deno.land/manual/linking_to_external_code , then I stand to what I said.
- nkozyra 5y ago
  But again - and this is mentioned in the page, nothing here is unique to Deno. It semantically feels different, but is in practice no different than most dependency management systems.
  - develatio 5y ago
    It feels broken, because it's a bad idea, per the design itself. Basically, you're ("you" as in figuratively speaking) smashing the functionality of a package manager into the interpreter. I'm not convinced at all that making a single tool do more and more stuff is a good idea, but let's keep on. Then, you're writing URLs (for the libraries you're importing) all over the code (which is just bad). Deno's solution (from the link in my prev reply) is to just put all the URLs in a single file (so, basically a "packages.json", but now inside your code, ¿because that's somehow a good idea?). Then there's the entire thing about replacing NPMJS, which has full-time engineers working on security, maintenance, etc... with a bunch of different servers, maybe maintained, maybe not, by random people. Then there's the entire "but how can I be sure that the code didn't change?" thing, to which Deno suggests to use a "--lock command flag". This sounds like "npm.lock / yarn.lock". And finally, there's the availability concern ("what happens if any of these servers goes down?"), which Deno just dismisses by saying that this can happen to any server. And while that is technically true, pulling all your dependencies from a single place, instead of N different places, reduces the points of failure to 1 (instead of N). So, this entire "import directly from URLs" sounds just like a package manager with different steps, without providing anything new, without fixing any specific problems with package managers, and introducing new problems (which are in fact old problem, because as I said, we've been there already when PHP thought remote includes were a good idea).
    - nkozyra 5y ago
      The lock concept isn't at all unique to npm/yarn because you need some form of checksum/hash verification. Even if you trust your source that's unlikely to be part of a repo and doesn't guarantee the next developer can trust what they get. Availability is a concern, but again if you have it once you have some way of including it in the project. I think there's a security nightmare with anything that's going to end up in browser at some point. It's such an exploitable surface. And PHP was not a thoughtfully designed language, but the bad part wasn't the fact that remote includes were possible but that there was no attempt at sandboxing or security built into the functionality. I'm not sold on Deno for what it's worth. I do agree with you on interpreter not really needing to be in charge of package management, but compilers do it all the time and most typescript ends up getting compiled or transpiled anyway.
  - forty 5y ago
    The difference is that you mix your code and package management. I'm not sure why the code would need to know where you obtained the dependency. This is package manager business. Whether you get the dependency from your git repo, from a centralized package repository or from a random url had nothing to do in the code.
    - ronsor 5y ago
      > The difference is that you mix your code and package management. To an extent, Go does the same thing, even though the modules slightly changed that.
      - nkozyra 5y ago
        I think this is a nit - most modern compiled languages do this but at the compiler level.

brundolf 5y ago

The thing is, somebody could (and maybe should!) launch a curated, versioned, audited package registry that just happens to operate through URLs. The URLs are just the mechanism; they make Deno less opinionated about where it gets its packages, but they don’t preclude something more managed and featureful like NPM.