331–340 of 598 posts
Earlier quoted context omitted.
Sure do. I wonder if they have a checksum mechanism like browsers do? You can add an “integrity” attribute to script tags in the browser. https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
One advantage of urls is that you can link to a specific git sha, tag, or branch for a dependency, e.g. on github.
Looks like my personal law/rule is in effect again: The harsher HN critics are, the more successful the product will be. I have no doubt Deno will be successful.
Nice. seems Deno is an anagram of Node.
Earlier quoted context omitted.
such is the curse of having the audacity to develop software :)
Sure, but there's a tendency to start over when the development gets hard to maintain or support instead of just fixing the mistakes. This really feels like the fundamental response in the js world and why we see much churn.
The dependency management is highly questionable for me. Apart from the security concerns raised by others, I have huge concerns about availability. In it's current form, I'd never run Deno on production, because dependencies have to be loaded remotely. I understand they are fetched once and cached, but that will not help me if I'm spinning up additional servers on demand. What if the website of one of the packages I…
Earlier quoted context omitted.
One advantage of urls is that you can link to a specific git sha, tag, or branch for a dependency, e.g. on github.
So exactly like existing tooling can already do, then?
Earlier quoted context omitted.
Security is literally the main selling point of this thing. Otherwise just use node.
There are a lot selling points. To me, the main one is typescript with no build.
yarn global add ts-node prettier
echo 'alias deno="ts-node"' >> ~/.zshrc
echo 'alias deno-fmt="prettier --write"' >> ~/.zshrc
Internals are nicer but that's with anything without ugly legacy.
They are working to get node_modules work in deno so I am kind of worried that it will be nodev2 all over.
The dependency management is highly questionable for me. Apart from the security concerns raised by others, I have huge concerns about availability. In it's current form, I'd never run Deno on production, because dependencies have to be loaded remotely. I understand they are fetched once and cached, but that will not help me if I'm spinning up additional servers on demand. What if the website of one of the packages I…
https://github.com/ChALkeR/notes/blob/master/Gathering-weak-...
- node ships with npm
- npm has a high number of dependencies
- npm does not implement good practices around authentication.
Can someone compromise npm itself? probably, according to that article.
Earlier quoted context omitted.
How is it any worse than using names from a namespace controlled by “npmjs.com”: if you’re concerned about build stability, you should be caching your deps on your build servers anyways.
I've never used npm or developed any javascript before but it sounds equally horrible. Not decoupling the source of the package (i.e., the location of the repository whether it is on remote or local) and its usage in the language is a terrible idea. from foo import bar # foo should not be a URL. It should just be an identifier. # The location of the library should not be mangled up in the code base. Are we gonna sear…
The issue you bring up can be solved in several ways: for example, xml solves it by allowing you to define local aliases for a namespace in the document that’s being processed. Npm already sort of uses the package.json for this purpose: the main difference is that npmjs.com hosts a centralized registry of module names, rather than embedding the mapping of local aliases->url in the package.json