I haven't tried deno yet but it seems like it doesn't have a single place where all of your dependencies are defined? That used to be package.json but they didn't replace it with anything? It's useful information to see a list of all dependencies of a project instead of having to check through each file to get this information.
Yes, Deno does not mandate a single file to list all your dependencies because that would require something like npm to assist that standard. But Deno tries to stay away from the idea of a single entity having control of all of the ecosystem. Deno is a javascript runtime and only a runtime.
For more info, check out this section of deno manual:
But this creates a problem for package authors who don't have a single place to distribute their packages. Deno authors have a system in place to make up for that, deno.land/x which is just a proxy to GitHub. If you want a more decentralised and immutable (you don't want another left-pad incident, do you?) platform to publish your packages, there is nest.land which is a platform independent package registry.
I would highly suggest you try out Deno. It's a step in the right direction. Deno actually prioritises using browser APIs instead of creating custom ones. This unifies the javascript ecosystem to some extent as now it is divided in server-side and client-side javascript, which look and work differently.
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I haven't tried deno yet but it seems like it doesn't have a single place where all of your dependencies are defined? That used to be package.json but they didn't replace it with anything? It's useful information to see a list of all dependencies of a project instead of having to check through each file to get this information.
Yes, Deno does not mandate a single file to list all your dependencies because that would require something like npm to assist that standard. But Deno tries to stay away from the idea of a single entity having control of all of the ecosystem. Deno is a javascript runtime and only a runtime.
For more info, check out this section of deno manual:
But this creates a problem for package authors who don't have a single place to distribute their packages. Deno authors have a system in place to make up for that, deno.land/x which is just a proxy to GitHub. If you want a more decentralised and immutable (you don't want another left-pad incident, do you?) platform to publish your packages, there is nest.land which is a platform independent package registry.
I would highly suggest you try out Deno. It's a step in the right direction. Deno actually prioritises using browser APIs instead of creating custom ones. This unifies the javascript ecosystem to some extent as now it is divided in server-side and client-side javascript, which look and work differently.