4 ms·

> His point was that the mere ability was the issue Can you elaborate? > so they're going against their original values because they know what they wanted isn

> His point was that the mere ability was the issue Can you elaborate? > so they're going against their original values because they know what they wanted isn't what the broader community wants. No, they are still sticking to everything, but added support for the existing ecosystem. Yes they are adding this to combat the network effect that node has, but it doesn't really go against anything. You simply prefix npm in front of npm imports. Now you could use a package.json file if you already have one, but you don't have to.

tsimionescu 4y ago
No. They are adding "deno:package@version" native imports, and they are adding a deno.json file to specify them. They are adding dependency resolution logic for these native deno packages to deno itself. The fact that all this interoperates with NPM as well is just an added bonus. But even if NPM died tomorrow, deno would go on having a package system, because they have realized how important it actually is (to fix things like what they call the "duplicate dependency problem").
- MrOwnPut 4y ago
  Yes and that is nice, it'll allow future import map support, like in the browser, which is inline with Deno's goal of using browser APIs instead of proprietary ones. But the package.json format part is a backwards compatibility feature. The preferred import maps will be the ideal solution (if you do need dependency management). None of that really goes against direct imports, which work well for single file scripts, workers, etc. Choose what fits.