5 ms·

> import 'https://cdn.jsdelivr.net/npm/marked@3.0.7/marked.min.js https://cdn.jsdelivr.net/npm/marked@3.0.7/marked.min.js'; Doesn't this mean your code won't

• int_19h 5y ago
  In Deno, you use vendoring. https://deno.land/manual@v1.20.1/tools/vendor.md https://deno.land/manual@v1.20.1/tools/vendor.md
  • nightski 5y ago
    Is this really a better workflow? I mean it works, but now you do not have a central list of all your external dependencies. Sure they recommend you just do all your imports in a single file and re-export them. But that sounds very tedious and at the end of the day to what advantage? I'm really struggling to see it.
    • zarzavat 5y ago
      It seems like a feature that would be better implemented at the IDE/editor level. Paste in a URL and it asks you if you want to add it to package management.
    • binarynate 5y ago
      For scripts, it's pretty sweet to be able to import dependencies directly via URL without needing to do an `npm init` and `npm install`. For larger projects (like my static site generator), I didn't find it tedious to import from a central deps.ts file, although I admit that importing from a relative path like '../../deps.ts' is not as quite as nice as importing by package name like in Node. I'm OK with that the tradeoff, though, especially since it matches the way imports work in the browser.
      • dmitriid 5y ago
        What about transitive dependencies?
        • galaxyLogic 5y ago
          My question too. I assume Demo downloads one component and then all its nested dependencies. But now every nested dependency can come from a different server, just like the components you refer to can come from anywhere on the internet. I wonder if this could be a security issue. It's hard to know who has control over all those nested repositories, and who keeps a look on them to ensure they are not maliciously modified? Is anybody checking on cryptographic signatures of them? Only asking because I don't know much about Demo.
          • int_19h 5y ago
            Locked modules have their hashes stored, so if something does change, you'll know right away. So will anybody else who got the source from you with lock.json included.
            • dmitriid 5y ago
              So, this is kinda unusable for any corporate setting where all dependencies, including transitive ones, are downloaded from a private server.
              • int_19h 5y ago
                Er, why? You'd just set up an import map to point it at your private server.
                • dmitriid 5y ago
                  > You'd just Ah. The enievitable "just". And how exactly do you set the import map to point to the private server for the transitive dependencies? Deno's own docs don't bother with such trivialities and show a very toy example, of course, https://deno.land/manual/linking_to_external_code/import_maps https://deno.land/manual/linking_to_external_code/import_map...
    • yesbabyyes 5y ago
      Rather than importing and re-exporting dependencies, Deno supports import maps: https://github.com/WICG/import-maps https://github.com/WICG/import-maps https://deno.land/manual@v1.20.1/linking_to_external_code/import_maps https://deno.land/manual@v1.20.1/linking_to_external_code/im...
• chaorace 5y ago
  Well... CDNs aren't supposed to go down, but if they do suffer an outage, Deno caches dependencies locally. If that's still not enough, you can also just download the JS file and import from a local path or use the vendoring feature.
  • playpause 5y ago
    Not sure that “CDNs aren’t supposed to go down” is a very reassuring point, nor one that Deno’s authors would make in its defence. Deno’s vendoring approach isn’t like a stopgap in case third party servers go down. It’s the ’right’ way in Deno, and is another brilliant fix to Node’s approach. Node always makes you go through a formal step to install a dependency - and then you’re still reliant on npm’s CDN being online during your builds anyway. The only way to break that build time dependency is to use a clunky, nonstandard hack to check in your node_modules, like yarn 2.0 or pnpm, which then takes you right off Node’s “golden path” (such as it is) and creates loads of incompatibilities. Deno’s approach is the best of both worlds. 1. With Deno you can import direct from a URL with no formal install step, which is great for prototyping. The caching engine makes it fast without a need for every little toy project to have to have a giant node_modules folder. 2. Vendoring your scripts provides a dead easy, golden-path way to make your project completely non-dependent on third party during build, ie gives you same advantage as using Yarn 2 or pnpm in Node, but as a first class citizen of the runtime, so it’s efficient and standardised and will therefore not have tons of ecosystem incompatibilities.
    • galaxyLogic 5y ago
      > you’re still reliant on npm’s CDN being online during your builds Why? I'm building my program out of components in my node_modules -folder. Why do I need internet?
      • playpause 5y ago
        I mainly meant CI/CD builds. Or any future build on a new machine.