8 ms·

I'd love to use deno, but I really don't understand the point deno's module/package system. The standard practice of deps.ts/dev_deps.ts as described in the do

• eevilspock 6y ago
  You realize Deno is founded by Ryan Dahl, who founded Node 12 years ago, don't you? Perhaps you should be less quick to label anything about it "asinine" or even "awful hack".
  • Twixes 6y ago
    With all respect to Ryan Dahl, I'm sure he'd disagree with the "asinine" characterization but would also disagree he's infallible - as evidenced by the creation of Deno after Node
    • eevilspock 6y ago
      I'm just saying Don't be so quick to judge. Be humble! No one is infallible. That said, creating Deno after Node doesn't imply that Node was a fail or that Deno will be perfect. Obviously not. Consider that someone really smart has reasons for doing (or trying to do) things a certain way. Be humble!
      • goldenkey 6y ago
        Node is a failure. It's standard library is written ad hoc. Riddled with catch 22s and monkey patches. The development style is just to bolt on more and more variables and branches, endlessly, without any cohesive style. Example of the "common caterpillar" genus of node quirks and the awful antagonistic responses by the dev team: https://github.com/nodejs/node/issues/25857 https://github.com/nodejs/node/issues/25857 Just take a look at a random stdlib source file: https://github.com/nodejs/node/blob/master/lib/readline.js https://github.com/nodejs/node/blob/master/lib/readline.js ``` if (input && input.input) { // An options object was given output = input.output; completer = input.completer; terminal = input.terminal; history = input.history; historySize = input.historySize; signal = input.signal; ``` It's junior-level code writing all over the project. That is a failure in my mind, especially when I know the library backing my project has to import all that junk hidden from view. See (wontfix) fs.promises.readFile is 40% slower than fs.readFile: https://news.ycombinator.com/item?id=26332774 https://news.ycombinator.com/item?id=26332774 Not to mention the awkward political nature. There is a BLM banner on their front page: https://nodejs.org https://nodejs.org .The founder of BLM, Patrisse Cullors, just bought 4 mansions, the last for $1.4 Million USD: https://news.yahoo.com/blm-official-calls-investigation-founder-114017918.html https://news.yahoo.com/blm-official-calls-investigation-foun... Node's dev team is not interesting in supporting the community. They are amateurs who are trying to be woke and add "top Node contributor" to their toolbelt of proverbial ego items. Prove me wrong.
        • pests 6y ago
          Most support BLM the concept, few know anything of BLM the organization.
          • goldenkey 6y ago
            The movement has been co-opted by opportunists just like Al Sharpton did 10 years ago. Police reform is an issue that everyone can get behind. But it's not as catchy and divisive.
        • agnoster 6y ago
          Always snopes before you post! https://www.snopes.com/fact-check/patrisse-cullors-topanga-house/ https://www.snopes.com/fact-check/patrisse-cullors-topanga-h... The "mansion" is a 3br 2ba, real estate is just kind of expensive in LA. My Bay Area home is actually worth more than that, and I don't see why she shouldn't be allowed to make real estate investments or have a nice-ish house. There's no evidence any funds have been misappropriated, and if it comes to light I'll join you in complaining, but until then it just kinda sounds like an attempt to discredit BLM-the-movement by discrediting it's leaders and organization without any real evidence.
  • zkldi 6y ago
    I do! And I think node has a lot of flaws (Ryan seems to agree). I do not understand why deno has gone for this route. It seems primed to produce a package manager eventually, and it seems like a bad idea to leave package manager creation down to whoever makes the first decent tool (which is mostly why npm is the standard for node.)
• vexna 6y ago
  I found most of the dependency woes to go away with import maps: https://deno.land/manual@v1.9.0/linking_to_external_code/import_maps https://deno.land/manual@v1.9.0/linking_to_external_code/imp...
  • zkldi 6y ago
    oh damn, that's exactly what i've wanted.
  • sujayakar 6y ago
    it seems like libraries can't use import maps though, right? the final binary can provide that flag, but is there a way for library dependencies to specify their own import maps? the spec [1] has support for scoping, but I didn't see a way to integrate that with the Deno loader. [1] https://github.com/WICG/import-maps#scoping-examples https://github.com/WICG/import-maps#scoping-examples
    • Soremwar 6y ago
      Yeah, libraries can't use import maps because import maps are not extensible
      • arcatek 6y ago
        It's almost like you need something to manage your packages to generate them.
  • nikisweeting 6y ago
    Except you have to make them manually. They could've trivially built a thing that takes your npm package.json and converts it to an import map internally, but instead you gotta manage all that hassle yourself because they don't want to play nice with npm. /rant
• dpweb 6y ago
  Not sure I’d use the local deps file. I really like just the import {..} from “https://..” https://xn--ivg. The version, everything, is up front and explicit.
  • anderskaseorg 6y ago
    The problem the deps.ts pattern solves is that your project has several dozen modules that all import a particular version of a dependency, and now you need to update them all to a new version of that dependency. (If your project only has one module, then you don’t have this problem and don’t need this solution.)
    • smallnamespace 6y ago
      Why not just use sed?
      • systemvoltage 6y ago
        Why bother with DRY at all? Just sed all day to replace 24 instances of function foo().
        • smallnamespace 6y ago
          Indeed, DRY is overrated, especially for trivial things like string constants.
          • goldenkey 6y ago
            How is DRY overrated? Making edits to a codebase shouldn't require any more tools than a text editor. I wouldn't want to live in a house that required powertools for every minor repair, it would be burdensome and indicate poor development practices.
            • smallnamespace 6y ago
• Soremwar 6y ago
  You do something like this export * as Oak from "https://deno.land/x/oak/mod.ts"; export * as Postgres from "https://deno.land/x/postgres/mod.ts"; Then you do this: import { Oak, Postgres } from "./deps.ts";
  • zkldi 6y ago
    > Do you namespace them yourself, or export an object under the name of the library (and therefore give up destructuring?) I know you can do this, but then you can't do import { Function1, Function2 } from "oak"; You could do import { Oak } from "./deps.ts"; const { Function1, Function2 } = Oak; But that is still an awful workaround.
    • searchableguy 6y ago
      There are user land tools to manage dependencies for you. I cannot comment on the specifics because I haven't used them extensively but one example is deno-udd. It updates your dependencies. https://github.com/hayd/deno-udd https://github.com/hayd/deno-udd There are one or two more feature rich ones. The need for deps.ts can be eliminated with management tools which work with your imports directly.
      • zkldi 6y ago
        That's just a package manager! If something like that is needed, then I think deno should attempt to come with something for managing dependencies. Eventually, developer convinience will win, and everyone will settle on some sort of package manager for deno. It'd probably be for the best if deno made it official as, personally, I think this is heading towards a second NPM.
        • searchableguy 6y ago
          Not quite the same. It's a simple management tool which rewrites your imports to use the latest version from supported registries. Deno binary still handles all the resolution, fetching, caching and loading. There are no plans to add such convenience in the binary because it would mean limiting places you can import from (cannot upgrade deps for unsupported registries). Deno binary will remain agnostic to where you import from. Community will come up with something if it's a huge problem and settle eventually.
• jFriedensreich 6y ago
  i like to have multiple deps files roughly grouped. this reduces not only the likelihood of name clashes but also gives a bit more structure and in addition when running in the browser its possible to handle bundling the dependencies separately by that grouping.
• apatheticonion 6y ago
  The issue is that JavaScript (by extension TypeScript) doesn't have the concept of folders. You can only import a single file per import statement. Developers create "barrel" files that allow them to re-export all of the important stuff in a folder externally. This allows for namespacing // foo/index.ts export * from './foobar' // main.ts import * as foo from './foo/index' new foo.Foobar() Or use destructured imports to help with static analysis tool that trace imports removing unused references from the final build // main.ts import { Foobar } from './foo/index' Node has non standard behaviour where it appends `/index` to the import path if it's a folder allowing you to shorten imports to import {} from './foo'
  • z3t4 6y ago
    Gotcha in ES6 import is that you need to import the default export specifically eg. import default as Foo, * as Bar It would be much easier if it was one namespace like in Node.js require. eg. var Foo = await requires("foo", {fs: "/home/user"}) Node.js modules are pretty much perfect besides the security flaws.
    • apatheticonion 6y ago
      Yeah I am sad that ES6 imports don't allow for easy namespacing. You can get around this with a double barrel. In the outer barrel, export your individual things // index.barrel.js export * from './foo.js' Then in your main barrel re-export them under a namespace // index.js export * as foobar from './index.barrel.js' Then from you application you are forced to have a named import with the namespace defined // main.js import { foobar } from './foobar/index.js' foobar.foo() You can submit a proposal to introduce namespacing to ES6 imports
• Osiris 6y ago
  If dependencies are imports from URLs, how does one audit their dependencies? If a server gets hacked those TS can be replaced with malicious versions. In npm we at least know that a package is immutable once published, someone could publish a malicious version as a newer release but a current release. Does demo generate some type of file that keeps a hash of all downloaded imports to verify against the next time those imports are downloaded?
  • tlrobinson 6y ago
    Integrity checking & lock files https://deno.land/manual@v1.9.0/linking_to_external_code/integrity_checking https://deno.land/manual@v1.9.0/linking_to_external_code/int... The same problem (and solution: package-lock.json or yarn.lock) exists in npm if you use semver version specifiers, or npm itself could be hacked, it’s just a bit more acute in Deno since it’s easy and common to load files from arbitrary hosts that don’t enforce immutable versions.
    • nikisweeting 6y ago
      npm has a lot more to lose from being hacked than some random URL, I trust npm with my packages because they fix stuff when something like left-pad happens, the same is not true for every URL I'd have to import to build a deno package.
  • dkdbejwi383 6y ago
    > In npm we at least know that a package is immutable once published, someone could publish a malicious version as a newer release but a current release. This is only true as long as you trust NPM. If they were hacked or taken over by a malicious actor, packages could be modified unbeknownst to you.
    • felixfbecker 6y ago
      No they could not. Because your package-lock.json contains integrity hashes that are verified during installation.
• ARussell 6y ago
  You could opt to improve upon the standard practice, right? I have only played with Demo a little, but the deps file seems only like a convention rather than a strict rule. Why not instead create a deps directory, and keep in it one file per dependency? Inside each file, you re-export the library from URL. This way you can import from files rather than URLs elsewhere in your code, and it should be clear which dependency is being imported from the file name itself.
  • zkldi 6y ago
    That solution is great! But it sounds like something that could be automated or managed for me.
• riho 6y ago
  This is probably one of the bigger issues holding me back from adopting Deno (at least for personal projects anyway). I'm sorry, I don't want to go back to early 2000s where we're copy pasting random links to script tags. Those days are over and for the better. NPM has proved pretty much undeniably that people prefer the simplicity of just typing in the name of something to install it, and import it. Does it have issues? Absolutely. I'd rather those issues be resolved than completely throwing away the concept though. This feels to me a bit like if a new browser came around and said "DNS is the root of all evil" and only allowed you to directly type in the IP address of websites. You can make all kinds of excuses, like "oh, but you can keep a list of your own!" or "hey, you can install this plugin that gives you DNS lookups back", but ultimately as a user I'm gonna say "No thanks, I'll keep using a browser that doesn't needlessly complicate my day." I'm usually an early adopter for this kind of stuff, and I really like a lot about Deno, which is why this situation just makes me very sad.
  • nikisweeting 6y ago
    This 100%. Every time it comes up I'm just saddened by the fact that they're so antagonistic towards the existing npm ecosystem, when those problems could be so easily solved and their userbase so easily expanded with some minor compatibility tooling that allows importing npm packages.