Siddharth makes a fantastic point. It is not like Deno does not bring along a way to manage your packages/dependencies. With that in mind, just because a method of doing something in one place works well, does not make it the superior method in another environment. It makes total sense for JS to have packages be imported via urls. Functionality can always be added on top to make it work like you are used to after the fact. People tend to think that a method of doing something is superior or the best just because they are used to it and not necessarily because it IS the better method.
My only concern is dependency management with URL imported packages. How would one go about changing the version of the package if it is been imported in 10 different places. Also solving resolution conflicts that package managers like yarn and npm perform when one package depends on several is quite handy. Having URL's is fine as long as there's a central way of managing the dependencies.
importlodashfrom'lodash';
vs
importlodashfrom'some-long-url/lodash';
I personally find the former easier to read and write. Also for autocomplete and intellisense, the dependencies need to be downloaded anyway.
My only concern is dependency management with URL imported packages. How would one go about changing the version of the package if it is been imported in 10 different places.
As I said here, Deno has a convention of putting all imports in a deps.ts file. This makes it easier to change versions, as there is only a single import.
Also solving resolution conflicts that package managers like yarn and npm perform when one package depends on several is quite handy.
Deno has no "magical" module resolution. Instead, imported modules are specified as files (including extensions) or fully qualified URL imports. This makes it harder to mess up.
I personally find the former easier to read and write.
If you use the deps.ts convention, you could have this:
deps.ts
import*as_from'some-long-url/lodash';// If you want it allexport{_};// If you need only someexport{uniq:_.uniq,isEqual:_.isEqual}
Deno has no "magical" module resolution. Instead, imported modules are specified as files (including extensions) or fully qualified URL imports. This makes it harder to mess up.
Great to know! Will try this out with deps.ts. Thanks!
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.
Siddharth makes a fantastic point. It is not like Deno does not bring along a way to manage your packages/dependencies. With that in mind, just because a method of doing something in one place works well, does not make it the superior method in another environment. It makes total sense for JS to have packages be imported via urls. Functionality can always be added on top to make it work like you are used to after the fact. People tend to think that a method of doing something is superior or the best just because they are used to it and not necessarily because it IS the better method.
My only concern is dependency management with URL imported packages. How would one go about changing the version of the package if it is been imported in 10 different places. Also solving resolution conflicts that package managers like
yarn
andnpm
perform when one package depends on several is quite handy. Having URL's is fine as long as there's a central way of managing the dependencies.vs
I personally find the former easier to read and write. Also for autocomplete and intellisense, the dependencies need to be downloaded anyway.
As I said here, Deno has a convention of putting all imports in a
deps.ts
file. This makes it easier to change versions, as there is only a single import.Deno has no "magical" module resolution. Instead, imported modules are specified as files (including extensions) or fully qualified URL imports. This makes it harder to mess up.
If you use the
deps.ts
convention, you could have this:deps.ts
main.ts
or wherever you use itDeno caches modules once they are required once, so intellisense can work at that time.
Yup
deps/ts
is a much better way :)Great to know! Will try this out with
deps.ts
. Thanks!