4 ms·
We don't ignore these problems. We find web compatible ways to solve them. If you had done just about 3 seconds of research before posting, you would have notic
by lucacasonato 5y ago
We don't ignore these problems. We find web compatible ways to solve them. If you had done just about 3 seconds of research before posting, you would have noticed we have support for import maps[1]. These elegantly solve the issue in a way that also works in the browser. No node_modules needed :-)
[1]: https://deno.land/manual@v1.13.1/linking_to_external_code/import_maps https://deno.land/manual@v1.13.1/linking_to_external_code/im...
- spankalee 5y agoImport maps are great if you know all the mappings you want to make. That requires that you know every way that conceptually the same packages are imported in the entire transitive module graph, which is hard enough on its own, but also requires crawling the whole live module graph to discover all the imports. I don't see how this isn't just npm-but-worse.
- whateveracct 5y agoIt'll eventually evolve into npm-but-different once Deno gains more adoption and its users learn they need a real package manager. And the cycle continues.
- whateveracct 5y agoThat looks like the output of a package manager (like a cabal freeze file), but if that's all you got then you don't have a package manager yet.
- andrew_ 5y agoprojects like `trex` [1] take the heavy lifting out of the equation, and are nicely compatible with a lockfile. This may feel familiar, even somewhat similar, but after using it for a short time I state with confidence that it's not a package manager. This paradigm is enjoyable. [1] https://nicedoc.io/crewdevio/Trex https://nicedoc.io/crewdevio/Trex