7 ms·

Deno 1.31: Package.json Support

114 points by mikece 4y ago

nikisweeting 4y ago
Hallelujah, I've been waiting for this for years. This was the one remaining thing I needed to transition to Deno. I got SO MUCH pushback every time I asked for this. Everyone on the Deno side was so righteous / moral high groundy about not adding package.json support and swore up and down that they never would because it goes against the entire ethos. I knew they would eventually cave and implement it, but I will hold my tongue on any further snark and just be appreciative that it's finally here, and thankful for all the hard work they put into implementing this difficult compatibility layer! ;)
- LniSggDer 4y ago
  [dead]
- haolez 4y ago
  It could become a mediocre project from now on. It's becoming a marginal improvement over Node at best.
  - throwanem 4y ago
    ...because it added package.json support?
    - haolez 4y ago
      Because it caved in in a core principle, which was to be a zero configuration JavaScript/TypeScript runtime environment. I don't use Deno. I'm making a thought exercise :)
      - lewantmontreal 4y ago
        You don’t need an import map on an existing project now, meaning it needs less configuration than before.
        ravenstine 4y ago
        When were import maps ever necessary? Pretty much every Deno project I've seen uses `deps.ts`. Only reason for import maps most of the time is for vanity module names, unless I'm mistaken.
        nikisweeting 4y ago
        They were useful for getting URLs out of your source code, which are inherently brittle.
        ravenstine 4y ago
        Isn't that exactly what a deps file does? Technically it's code, but it's serving the same purpose of keeping the URLs in one place. It seems like the only unique function that import maps serve in Deno is so that, instead of importing from "./deps.ts", you're importing from arbitrary identifiers. Which is fine, but I wouldn't say that import maps are ever needed in Deno. It was always possible to organize dependencies in a TS/JS file and import from its module.
        nikisweeting 4y ago
        The issue is that being code it's turing complete and not parsable by other tooling easily. Having it in a config format (yaml, json, etc.) is easier for other tooling to inspect. infrastructure as data > infrastructure as code
        ravenstine 4y ago
        One of the reasons behind ES module syntax was to make imports/exports statically analyzable. Sure, it's technically simpler and more portable to use JSON, but a tool that fits all more use cases isn't necessarily the best tool for the most common use cases. Given that all import maps are just maps of names to URLs, I see no reason why a JS module couldn't be trivially parsed to inspect what URLs are being imported and what identifiers are being exported.
  - nikisweeting 4y ago
    Strong disagree, Deno gets so many things right that are really different from Node, package.json is just a small piece. A compatibility layer to allow large projects to migrate doesn't compromise Deno's principles as long as they don't change the Deno docs to point greenfield users towards package.json by default.
  - qbasic_forever 4y ago
    Marginal improvement? Uhh, for a greenfield deno project it's light-years more productive than node and npm. You directly import dependencies by URL and never have to touch or know about a package manager, node_modules folder, etc. You have a fully featured standard library and don't have to download third party code for stuff like left padding a string. You have typescript transpilation out of the box and with zero config vs. sometimes hours of fiddling and fuss with node. You have ES modules by default and none of this nonsense about .cjs vs. .mjs etc. It's a much more opinionated ecosystem and that's a good thing IMHO. I think people mad about this and node support in general don't realize it's just a quality of life thing for people moving existing code over to deno. Instead of being like python 3 that firmly said "just rewrite your code, stop complaining" the deno folks are giving people an easier way with compatibility to node.
  - berry_sortoro 4y ago
    [dead]
- deleted 4y ago
  [deleted]
- throwingrocks 4y ago
  Not sure what's more impressive. You holding out for years for this feature or Deno's implementation.
  - nikisweeting 4y ago
    It was kind of a show-stopper missing feature if you had a large JS project with many NPM dependencies that you wanted to migrate slowly to Deno. I was not their target demographic before, but I'd guess this means things are changing as they want to scale and gain mass adoption, which sometimes takes bending principles to build a better compatibility and transition UX. For the record I'm really not asking them to favor package.json or even document it that well, they should still push new users towards the awesome Deno principles that get the industry away from NPM dependency hell. I just think compatibility layers are important for mass adoption, and don't necessarily imply Deno is "compromising" on their principles.
- SyrupThinker 4y ago
  > I knew they would eventually cave and implement it […] Let’s see how long it takes until Deno is just NodeJS Mark 2, with little value of adopting it. Hopefully the answer is never, but considering the type checking changes last year and deprecation of bundle now I have little faith that the features that, at least to me, made Deno a worthwhile improvement over NodeJS will stay.
seumars 4y ago
All the recent Node-related features are bound to alienate their core audience but I wonder to what extent.
- beebeepka 4y ago
  What are the drawbacks of these changes? I haven't been following deno very closely.
  - teg4n_ 4y ago
    IMO the appeal of Deno was an opportunity to rethink the JavaScript ecosystem. The introduction of all these Node features make it far more likely that things stay the same way they currently exist with Node, making it feel pointless to bother with Deno at all in the first place.
    - postalrat 4y ago
      Is package.json required?
      - imbnwa 4y ago
        Not required, but perhaps contagious
        nikisweeting 4y ago
        This is a valid concern but I think they can mitigate it with social pressure, documentation, and public success stories from users that fully eschew the old system. Hopefully not everything has to be as contagious as POSIX compatibility was for OS's.
    - CuriouslyC 4y ago
      except that if deno fails because its uptake cost makes it hard for engineers to sell to their org, what does it accomplish then? At least if it's getting used heavily people can invest engineering effort into the ecosystem on company time.
nawgz 4y ago
Deno fans, how are you using this language? I think they have some interesting ideas, but it increasingly just integrates Node.JS features, and from a casual observer's viewpoint I'm not entirely sure I understand what their initial goals were and if they have drifted far from them. It looks like compromised principles from where I sit, which can often be a bad thing - especially because package.json was one of the best parts of NodeJS and so it looks like their principles were made without a plan. Thoughts?
- llanowarelves 4y ago
  Start off by doing things the deno-"native" way and it's very fun. Most or all of the js tooling woes go away. It starts as just a .ts file that works. I love it for small CLI utilities. There are some quirks[0] but it's well designed UX overall. Stuff like node stdlib support is a necessary evil for some things. Like sharp (libvips binding) and nestjs didnt work at all before that iirc. And alternatives a lot of work to make. 0: https://github.com/denoland/deno_std/discussions/2102 https://github.com/denoland/deno_std/discussions/2102
- hobofan 4y ago
  > especially because package.json was one of the best parts of NodeJS and so it looks like their principles were made without a plan Yes, that's very much my impression as well. Their approach to package management feels very much like throwing out the baby with the bathwater. Sure, it's nice to naively import your dependencies from some random URL like it's 2005, but there is a good reason why the JS ecosystem at large has moved away from that. And while the npm ecosystem has some problems, npm (and preferably pnpm) is a package manager of a quality that few other programming languages have. Deno seems like a nice "fun" runtime for throwaway weekend projects, but most of the things that make it "fun" come from ignoring complexity that will fall on your feet once you try to do anything more sophisticated.
  - buzzerbetrayed 4y ago
    I still have never understood why people consider the lack of package management in Deno a plus. It sounded interesting to me when I very first watched the deno sales pitch back in the day. But when I tried to use it for something non trivial it was so clearly worse to me. To each their own I guess
ravenstine 4y ago
I can't say I appreciate adding package.json support, but I also don't see it as necessarily a bad thing. In my opinion, it would be a bad thing if this encouraged everyone to start using Deno as a stand-in for Node and make more Node patterns typical in Deno development. If package.json is there merely for backwards compatibility then that's one thing. On the other hand, if things drift towards doing everything the Node way again... well, I'm sure there's someone this very moment writing a "better" package manager for Deno that "solves everything for real this time." And I don't look forward to the flurry of package managers for Deno. Who's ready to decide whether "nary" is better than "dpm" or "pdpm"?
- nikisweeting 4y ago
  Exactly, I hope Deno gaining mass adoption will move the industry away from NPM dependency hell. This is just a stepping stone to get more projects on board with that mission by giving them a practical migration path from the old system.
- wokwokwok 4y ago
  > it would be a bad thing if this encouraged everyone to start using Deno as a stand-in for Node and make more Node patterns typical in Deno development It’s hard to see how adding package.json and the node compatibility layer is not going to make this like pypy. Ie. Highly compatible, technically distinct, practically irrelevant and not quite perfect dropin replacement for just using node to run your “designed for node” code.
  - nikisweeting 4y ago
    For one pypy doesn't offer an entirely new security model or standard library that displaces hundreds if not thousands of old 3rd party packages.
j-pb 4y ago
Downgrading the user experience of native deno users for the sake of nodejs compatibility is a huge bummer. Deno bundle was really really nice, and often times good enough for browser deploys.
conaclos 4y ago
This feature created a lot of debate [0]. However, I think it is a good thing to ease transition. I could also appreciate that Deno accepts importing ts files from a js extension. This could make Deno compatible with regular bundlers such as esbuild. [0] https://github.com/denoland/deno/issues/17491 https://github.com/denoland/deno/issues/17491

114 points by mikece 4y ago

Hallelujah, I've been waiting for this for years. This was the one remaining thing I needed to transition to Deno. I got SO MUCH pushback every time I asked for this. Everyone on the Deno side was so righteous / moral high groundy about not adding package.json support and swore up and down that they never would because it goes against the entire ethos. I knew they would eventually cave and implement it, but I will hold my tongue on any further snark and just be appreciative that it's finally here, and thankful for all the hard work they put into implementing this difficult compatibility layer! ;)

LniSggDer 4y ago
[dead]
haolez 4y ago
It could become a mediocre project from now on. It's becoming a marginal improvement over Node at best.
- throwanem 4y ago
  ...because it added package.json support?
  - haolez 4y ago
    Because it caved in in a core principle, which was to be a zero configuration JavaScript/TypeScript runtime environment. I don't use Deno. I'm making a thought exercise :)
    - lewantmontreal 4y ago
      You don’t need an import map on an existing project now, meaning it needs less configuration than before.
      - ravenstine 4y ago
        When were import maps ever necessary? Pretty much every Deno project I've seen uses `deps.ts`. Only reason for import maps most of the time is for vanity module names, unless I'm mistaken.
        nikisweeting 4y ago
        They were useful for getting URLs out of your source code, which are inherently brittle.
        ravenstine 4y ago
        Isn't that exactly what a deps file does? Technically it's code, but it's serving the same purpose of keeping the URLs in one place. It seems like the only unique function that import maps serve in Deno is so that, instead of importing from "./deps.ts", you're importing from arbitrary identifiers. Which is fine, but I wouldn't say that import maps are ever needed in Deno. It was always possible to organize dependencies in a TS/JS file and import from its module.
        nikisweeting 4y ago
        The issue is that being code it's turing complete and not parsable by other tooling easily. Having it in a config format (yaml, json, etc.) is easier for other tooling to inspect. infrastructure as data > infrastructure as code
        ravenstine 4y ago
        One of the reasons behind ES module syntax was to make imports/exports statically analyzable. Sure, it's technically simpler and more portable to use JSON, but a tool that fits all more use cases isn't necessarily the best tool for the most common use cases. Given that all import maps are just maps of names to URLs, I see no reason why a JS module couldn't be trivially parsed to inspect what URLs are being imported and what identifiers are being exported.
- nikisweeting 4y ago
  Strong disagree, Deno gets so many things right that are really different from Node, package.json is just a small piece. A compatibility layer to allow large projects to migrate doesn't compromise Deno's principles as long as they don't change the Deno docs to point greenfield users towards package.json by default.
- qbasic_forever 4y ago
  Marginal improvement? Uhh, for a greenfield deno project it's light-years more productive than node and npm. You directly import dependencies by URL and never have to touch or know about a package manager, node_modules folder, etc. You have a fully featured standard library and don't have to download third party code for stuff like left padding a string. You have typescript transpilation out of the box and with zero config vs. sometimes hours of fiddling and fuss with node. You have ES modules by default and none of this nonsense about .cjs vs. .mjs etc. It's a much more opinionated ecosystem and that's a good thing IMHO. I think people mad about this and node support in general don't realize it's just a quality of life thing for people moving existing code over to deno. Instead of being like python 3 that firmly said "just rewrite your code, stop complaining" the deno folks are giving people an easier way with compatibility to node.
- berry_sortoro 4y ago
  [dead]
deleted 4y ago
[deleted]
throwingrocks 4y ago
Not sure what's more impressive. You holding out for years for this feature or Deno's implementation.
- nikisweeting 4y ago
  It was kind of a show-stopper missing feature if you had a large JS project with many NPM dependencies that you wanted to migrate slowly to Deno. I was not their target demographic before, but I'd guess this means things are changing as they want to scale and gain mass adoption, which sometimes takes bending principles to build a better compatibility and transition UX. For the record I'm really not asking them to favor package.json or even document it that well, they should still push new users towards the awesome Deno principles that get the industry away from NPM dependency hell. I just think compatibility layers are important for mass adoption, and don't necessarily imply Deno is "compromising" on their principles.
SyrupThinker 4y ago
> I knew they would eventually cave and implement it […] Let’s see how long it takes until Deno is just NodeJS Mark 2, with little value of adopting it. Hopefully the answer is never, but considering the type checking changes last year and deprecation of bundle now I have little faith that the features that, at least to me, made Deno a worthwhile improvement over NodeJS will stay.

seumars 4y ago

All the recent Node-related features are bound to alienate their core audience but I wonder to what extent.

beebeepka 4y ago
What are the drawbacks of these changes? I haven't been following deno very closely.
- teg4n_ 4y ago
  IMO the appeal of Deno was an opportunity to rethink the JavaScript ecosystem. The introduction of all these Node features make it far more likely that things stay the same way they currently exist with Node, making it feel pointless to bother with Deno at all in the first place.
  - postalrat 4y ago
    Is package.json required?
    - imbnwa 4y ago
      Not required, but perhaps contagious
      - nikisweeting 4y ago
        This is a valid concern but I think they can mitigate it with social pressure, documentation, and public success stories from users that fully eschew the old system. Hopefully not everything has to be as contagious as POSIX compatibility was for OS's.
  - CuriouslyC 4y ago
    except that if deno fails because its uptake cost makes it hard for engineers to sell to their org, what does it accomplish then? At least if it's getting used heavily people can invest engineering effort into the ecosystem on company time.

nawgz 4y ago

Deno fans, how are you using this language? I think they have some interesting ideas, but it increasingly just integrates Node.JS features, and from a casual observer's viewpoint I'm not entirely sure I understand what their initial goals were and if they have drifted far from them. It looks like compromised principles from where I sit, which can often be a bad thing - especially because package.json was one of the best parts of NodeJS and so it looks like their principles were made without a plan. Thoughts?

llanowarelves 4y ago
Start off by doing things the deno-"native" way and it's very fun. Most or all of the js tooling woes go away. It starts as just a .ts file that works. I love it for small CLI utilities. There are some quirks[0] but it's well designed UX overall. Stuff like node stdlib support is a necessary evil for some things. Like sharp (libvips binding) and nestjs didnt work at all before that iirc. And alternatives a lot of work to make. 0: https://github.com/denoland/deno_std/discussions/2102 https://github.com/denoland/deno_std/discussions/2102
hobofan 4y ago
> especially because package.json was one of the best parts of NodeJS and so it looks like their principles were made without a plan Yes, that's very much my impression as well. Their approach to package management feels very much like throwing out the baby with the bathwater. Sure, it's nice to naively import your dependencies from some random URL like it's 2005, but there is a good reason why the JS ecosystem at large has moved away from that. And while the npm ecosystem has some problems, npm (and preferably pnpm) is a package manager of a quality that few other programming languages have. Deno seems like a nice "fun" runtime for throwaway weekend projects, but most of the things that make it "fun" come from ignoring complexity that will fall on your feet once you try to do anything more sophisticated.
- buzzerbetrayed 4y ago
  I still have never understood why people consider the lack of package management in Deno a plus. It sounded interesting to me when I very first watched the deno sales pitch back in the day. But when I tried to use it for something non trivial it was so clearly worse to me. To each their own I guess

ravenstine 4y ago

I can't say I appreciate adding package.json support, but I also don't see it as necessarily a bad thing. In my opinion, it would be a bad thing if this encouraged everyone to start using Deno as a stand-in for Node and make more Node patterns typical in Deno development. If package.json is there merely for backwards compatibility then that's one thing. On the other hand, if things drift towards doing everything the Node way again... well, I'm sure there's someone this very moment writing a "better" package manager for Deno that "solves everything for real this time." And I don't look forward to the flurry of package managers for Deno. Who's ready to decide whether "nary" is better than "dpm" or "pdpm"?

nikisweeting 4y ago
Exactly, I hope Deno gaining mass adoption will move the industry away from NPM dependency hell. This is just a stepping stone to get more projects on board with that mission by giving them a practical migration path from the old system.
wokwokwok 4y ago
> it would be a bad thing if this encouraged everyone to start using Deno as a stand-in for Node and make more Node patterns typical in Deno development It’s hard to see how adding package.json and the node compatibility layer is not going to make this like pypy. Ie. Highly compatible, technically distinct, practically irrelevant and not quite perfect dropin replacement for just using node to run your “designed for node” code.
- nikisweeting 4y ago
  For one pypy doesn't offer an entirely new security model or standard library that displaces hundreds if not thousands of old 3rd party packages.

j-pb 4y ago

Downgrading the user experience of native deno users for the sake of nodejs compatibility is a huge bummer. Deno bundle was really really nice, and often times good enough for browser deploys.

conaclos 4y ago

This feature created a lot of debate [0]. However, I think it is a good thing to ease transition. I could also appreciate that Deno accepts importing ts files from a js extension. This could make Deno compatible with regular bundlers such as esbuild. [0] https://github.com/denoland/deno/issues/17491 https://github.com/denoland/deno/issues/17491