7 ms·
Why we added package.json support to Deno
- jonorsi 4y agoMy first draw to deno was to escape npm and the node_modules blackhole :(
- timini 4y agoThe biggest issue with node.js was the terrible package manager. Looks like Deno is gonna make all the same mistakes.
- goodoldneon 4y agoThe anti package.json sentiment seems too puritanical. Sure there are downsides to it but I've rarely had a negative experience with it
- rektide 4y agoNpm has had such a rocky marginal existence for so many years, getting bought out & passed around, getting random-ish backing & support to stay afloat. Now Microsoft owns Npm package repo & seems like a trustworthy-ish benevolent dictator & stable, but it's more than just ideologically gross to have all the tens of millions of eggs in one basket, it's a constraint on exploration & growth & trying other paths. I think simply being free to try for better is a necessary & obvious step for js. It's not puritanical at all, it's embracing a lost freedom, to improve & figure stuff out.
- rilut 4y agoagreed, they got rid of package.json just for them to rediscover its convenience and reinvent it later
- robertlagrant 4y agoIt is fairly bad. The scripts section, which can't call other scripts sections neatly, is the worst.
- jadbox 4y agoTbh, i think the scripts section is what makes package.json become a mess. It's the #1 reason why packages break and why it takes forever to install some packages. If your package requires building, it's better to just create NPM/package build artifacts ahead of time.
- robertlagrant 4y agoAgree. Other than that it's decent. I say package.json with a minimal scripts section (so you can run dependency commands) and pop the composition of those commands in a Makefile.
- eropple 4y agoOne of the tricky things, and one of the reasons everybody reinvents the wheel, is that Makefiles aren't portable to Windows, which is a first-class platform for these runtimes. So you get a lot of second-system effect as a sidecar to "runs on Windows". (I don't think you as an individual should worry about Windows if that isn't a platform you care about, of course. But they have to.)
- robertlagrant 4y agoI wonder if npm for Windows just installing a wrapper for GNU Make, made available as npm run make, would solve that.
- 9dev 4y agoTangent - Why hasn't anyone ported make to windows yet? Isn't it "just" a task runner at the end of the day?
- eropple 4y ago`make` has been ported long ago! The problem is that almost every Makefile wants a reasonably large subset of POSIX stuff, when it doesn't want specifically GNU stuff. (And like, I write specifically GNUmakefiles because I don't care about those platforms.) `make` being portable doesn't help that `mv` and `cp` and all that don't port amazingly well. You can write binaries for them that take POSIX flags, of course, and people have, but now, to replace package.scripts with a Makefile, you have to pack a whole bootleg quasi-POSIX environment alongside your JS interpreter? That's not really going to fly with most people. But assuming you do that--how do you write a loop that works in sh, cmd.exe, and PowerShell? You get the idea. The only way to make a Makefile a real, cross-platform tool is to bring a Unix with it. And that's not super practical in a lot of places! So instead Node (or Ruby/Rake, etc.) converge to a point where libraries like `rimraf` are both really annoying and kind of essential for building an adequate cross-platform dev experience. Again: not endorsing. But it is why it's the way it is.
- HeavyFeather 4y ago> I've rarely had a negative experience with it We all bury bad memories. Feels like yesterday TypeScript couldn’t resolve a package because I set “moduleResolution: node16” Oh wait, that’s still happening, because a dependency does not use the correct package.json exports setup.
- joshmanders 4y agoGot VC funding and now they realize their “we just want cool little scripts to do things” isn’t what the community wants, now Deno is gonna be Node but with TypeScript as a first class citizen and way less friendly.
- deleted 4y ago[deleted]
- est31 4y agoBut why json? json is only marginally human-editable as its pure version doesn't even support comments. toml is way nicer for this purpose I think.
- explaininjs 4y agoFor one, JSON has native support in the very language this runtime supports.
- fulafel 4y agoDeno has TOML in the standard library too.
- hombre_fatal 4y agoI thought TOML was nice until I tried writing a parser that handled nested tables. There's very little convergence between libraries because it's such a hard / ambiguous problem. I thought I was making good progress until I tried burntsushi's edge case test suite. It reminded me of implementing YAML. TOML is slightly nicer to write than JSON if your structure is flat, like a php.ini or Cargo.toml file. Other than that, I prefer the simplicity of JSON as well as the buy-in of JSON Schema support in apps like VS Code. We too often do this thing as craftspeople where we dramatize how much minor pain points impact our lives while ignoring the upsides.
- est31 4y agoI agree that nested data is a weak point of TOML. But writing TOML files that don't have huge levels of nesting is a charm, which would be precisely the place where php.ini, Cargo.toml and package.json operate in. Deno had the chance to innovate here, but they missed out on it.
- andrewstuart 4y agoThis is the right way to go. Nodejs is “good enough”. package.json is entrenched. Deno gains nothing from not supporting package.json, and has everything to gain from becoming a “better node than node”. Deno will pick up steam if it can become a drop in replacement for nodejs. Then people can start to exploit its unique features. Ideally I could replace node and switch to deno by doing “npm install deno” from within an existing node project
- wrongcarwhy 4y agoReading the reasons...I could have told you this when Deno was released. Oh wait, pinned package versions are too specific??? Maybe you want some sort of tool where you can give it constraints on package versions and it'll find the minimal set that fits these constraints. Some sort of...package manager? And big url imports are kind of ugly no? If only there was a way to resolve them via a manifest that this package manager could also read. Some sort of package...file, like a package.json. I dunno man, this feels like stuff the Deno people could have predicted. I don't understand why people treat packages like the boogeyman. You need a way to share and reuse libraries. Then you need a way to version these libraries. Then you need a way to reuse versions of said libraries. Then you need a manager to handle the reusing and constraint solving of libraries. It's a pretty logical sequence of events. I know it seems icky and gross and we should all just be real programmers and write our own dependencies, but you don't get paid to write dependencies. I guess that's the issue. The people who write stuff like Deno or Node do indeed get paid to write dependencies. And it's too easy to listen to the people complaining about straw men like is-odd when in fact, for all the messiness, developers get a lot of utility out of packages.
- explaininjs 4y ago> You don't get paid to write dependencies. I guess that's the issue. The people who write stuff like Deno or Node do indeed get paid to write dependencies. Brilliant take. I realized something similar yesterday when my twitter feed was filled with people saying SSR/edge compute is the future... wait a second, you all work at Vercel, you make money by me computing stuff server side!
- chatmasta 4y agoI wish Vercel (or Zeit at the time) never abandoned their original model of running arbitrary Docker containers at the edge. I understand the desire to focus on one platform, but you could implement a lot more interesting use cases with arbitrary serverless containers, especially if the build process was as smooth and integrated with GitHub as it is for JS (although arguably a big reason for that smoothness is the focus on one platform).
- 4y ago
- paxys 4y agoDeno is the perfect real world example of a programmer looking at the complicated mess of code they wrote over many years, deciding to start fresh to fix all the problems, realizing their simple and elegant new product does not address all the use cases that the old one did, adding more and more complexity to it until it does, and eventually ending up with exactly what they had before.
- berry_sortoro 4y ago[dead]
- draw_down 4y agoAt least we get typescript, I guess.
- paxys 4y agoTypescript support has always been a one line addition to Node.js. What Deno did (moving ts-node to just work automatically behind the scenes) was nice to have but not exactly revolutionary.
- rektide 4y agoIf you are doodling around ts-node is great, but if you ever want to produce a ts library someone else might want to use it immediately becomes a endless eldritch nightmare maze of byzantine frustrating options almost all of which come with trade-offs. Having typescript built in, having zero complexity, none of these compile-down difficulties is just so liberating, so much bad you don't have to tangle with.
- soderfoo 4y agoWhen looking at my old code my internal dialogue flips between "What an idiot I was for writing this code" and "So brilliant and performant! I could never write code like this now."
- 4y ago
- pictur 4y agoDeno seems to have decided to try to solve problems by facing the past. This is really good.
- mrozbarry 4y agoOne thing I'm curious about is if it's just possible to sort of roll your own package version manager as part of your deno app. For instance, the current thing, from what I understand, is <code>import foo from 'https://some-cdn/your-library@^1.1.1'</code> https://some-cdn/your-library@^1.1.1'</code> and deno loads that in. The problem that adding a package.json solves (also, from my limited understanding) is for cases when you import this library in several places and have different version requirements. So, why not have something like: export const libraries = { "some-library": "https://your-cdn/some-library@^1.1.1", }; export const load = (library) => import(libraries[library]); Wouldn't that mostly solve the problem without just doing what NodeJS does?
- illiarian 4y agoBecause now you have to write this manually for every package. And how do you deal with dependencies of that package that also need to be fetched from `your-cdn`? Oh, perhaps write them in a JSON form in some sort of package.json and read them from there perhaps?
- joshmanders 4y ago> Oh, perhaps write them in a JSON form in some sort of package.json and read them from there perhaps? Maybe even have an executable that will read this file and understand your dependency graph and needs and install everything for you, and also allow you to keep it up to date. Maybe put this in `utils/npm.js` // short for node package manager. Brilliant. Lets all implement our own.
- mrozbarry 4y agoWell, you wouldn't need to for every package, it really depends on what you're bringing in and what dependencies they have. I do see your point, though.
- rektide 4y agoBare specifiers has been the tragedy of ESM. Nice module syntax... that is utterly u deoyable & which has had to have awful de-modularizing specifiers hard-coded into each file to make it work. Abominable sin to introduce "modules" to JS/es2015 then spend a decade dragging everyone along with no story for how to have modular modules. Import-maps are like "here" to fix this on the web... finally... except they only are shipping to the happiest sunniest easiest case, with Web Workers being totally shit out of luck in spite of some very simple straightforward suggested paths forward. https://github.com/WICG/import-maps/issues/2 https://github.com/WICG/import-maps/issues/2 I think Deno is making pretty good tradeoffs along the way here. This looks like package.json at surface level, but there is a nightmare of complexity under the surface. Typescript, ESM, cjs all have various pressures they create & in Node it's just incredibly tight & tense dealing with packaging, where-as Deno's happy path of Typescript first does not slowly tatters one over time. It really has been super pleasant being free of the previous world, and having something much more web-platform centric, more intented, with less assembly & less building, and more doing the actual coding. I confess I'm a bit surprised by this tack. The duplicate module issue felt somewhat solveable my offering more http urls... https://deno.land/std@0.179.0/uuid/mod.ts https://deno.land/std@0.179.0/uuid/mod.ts could be turned to https://deno.land/std@0/uuid/mod.ts https://deno.land/std@0/uuid/mod.ts to pick just the major version. Also notably these un-pinned imports are going somewhat the opposite direction from hopefully upcoming work on subresource integrity in import-maps, where we we can really pin versions, https://github.com/WICG/import-maps/issues/221 https://github.com/WICG/import-maps/issues/221 I really hope import-maps eventually get broader support. Maybe this long-dwelling webworker issue should be brought up with WinterCG.
- singularity2001 4y agoalmost! now separate the namespaces from the imports and we are good: "imports": { "@namespace":"deno", "oak": "oak@12",