5 ms·

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 fo

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.

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.