3 ms·

You can use import maps too: https://deno.land/manual/linking_to_external_code/import_maps https://deno.land/manual/linking_to_external_code/import_map... Deno

You can use import maps too: https://deno.land/manual/linking_to_external_code/import_maps https://deno.land/manual/linking_to_external_code/import_map... Deno's philosophy is to be aligned with web browser standards. I suspect import maps will be the path forward for most projects as it's what browsers will or are supporting today too.

dmitriid 4y ago
> You can use import maps too Again looks like package.json with many manual steps in between (where to get those import maps is the first question). Also, apparently non-composable etc. https://news.ycombinator.com/item?id=32469280 https://news.ycombinator.com/item?id=32469280 > Deno's philosophy is to be aligned with web browser standards. And yet they want to be able to run npm packages...
- qbasic_forever 4y ago
  Package.json is a mess, it combines a million different concerns like project metadata, dev environment, scripts, and random key/value pairs along with all the dependency information. It's a node and npm specific configuration that ballooned into a dumping ground for metadata. There's no reason to keep it around in a new runtime. You create the import map by figuring out what dependencies you want to use and crafting it and your code to reference them. You can do anything--you can import five different versions of the same library but under different names if you want. This was not something even possible with node and npm. You can make it as simple or as complex as your needs require. For most people they'll keep it simple and drop a few import urls directly in their source, never even needing to touch a tool or other file to worry about dependencies. They're giving users what they want, an ability to run packages which haven't been ported to work with deno yet. The blog post explicitly makes this clear. This is not some grand conspiracy like so many replies seem to be trying to imply.
  - dmitriid 4y ago
    > You create the import map by figuring out what dependencies you want to use and crafting it Ah yes. Truly the same amount of effort as package.json. How exactly do you figure out all dependencies (including transitive ones) and "craft" that? Edit TIL you can install as many versions under different names as you want with npm: https://medium.com/weekly-webtips/how-to-install-multiple-versions-of-the-same-package-in-npm-71c29b12e253 https://medium.com/weekly-webtips/how-to-install-multiple-ve... > This is not some grand conspiracy like so many replies seem to be trying to imply. There's no conspiracy. All the awkward workarounds with tedious manual steps to recreate a package.json "dependencies" field are frankly laughable. Deno should bite the bullet and automate this since they already have the dependency resolution built in. No need to "craft" anything.

dmitriid 4y ago

> You can use import maps too Again looks like package.json with many manual steps in between (where to get those import maps is the first question). Also, apparently non-composable etc. https://news.ycombinator.com/item?id=32469280 https://news.ycombinator.com/item?id=32469280 > Deno's philosophy is to be aligned with web browser standards. And yet they want to be able to run npm packages...

qbasic_forever 4y ago
Package.json is a mess, it combines a million different concerns like project metadata, dev environment, scripts, and random key/value pairs along with all the dependency information. It's a node and npm specific configuration that ballooned into a dumping ground for metadata. There's no reason to keep it around in a new runtime. You create the import map by figuring out what dependencies you want to use and crafting it and your code to reference them. You can do anything--you can import five different versions of the same library but under different names if you want. This was not something even possible with node and npm. You can make it as simple or as complex as your needs require. For most people they'll keep it simple and drop a few import urls directly in their source, never even needing to touch a tool or other file to worry about dependencies. They're giving users what they want, an ability to run packages which haven't been ported to work with deno yet. The blog post explicitly makes this clear. This is not some grand conspiracy like so many replies seem to be trying to imply.
- dmitriid 4y ago
  > You create the import map by figuring out what dependencies you want to use and crafting it Ah yes. Truly the same amount of effort as package.json. How exactly do you figure out all dependencies (including transitive ones) and "craft" that? Edit TIL you can install as many versions under different names as you want with npm: https://medium.com/weekly-webtips/how-to-install-multiple-versions-of-the-same-package-in-npm-71c29b12e253 https://medium.com/weekly-webtips/how-to-install-multiple-ve... > This is not some grand conspiracy like so many replies seem to be trying to imply. There's no conspiracy. All the awkward workarounds with tedious manual steps to recreate a package.json "dependencies" field are frankly laughable. Deno should bite the bullet and automate this since they already have the dependency resolution built in. No need to "craft" anything.