[HN Gopher] Deno 1.31: Package.json Support
___________________________________________________________________
Deno 1.31: Package.json Support
Author : mikece
Score : 71 points
Date : 2023-02-24 15:16 UTC (7 hours ago)
(HTM) web link (deno.com)
(TXT) w3m dump (deno.com)
| ravenstine wrote:
| 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 wrote:
| 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.
| nawgz wrote:
| 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?
| hobofan wrote:
| > 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.
| llanowarelves wrote:
| 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
| petre wrote:
| > It looks like compromised principles from where I sit, which
| can often be a bad thing
|
| Or they're not fuamentalists.
| nikisweeting wrote:
| 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! ;)
| haolez wrote:
| It could become a mediocre project from now on. It's becoming a
| marginal improvement over Node at best.
| qbasic_forever wrote:
| 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.
| nikisweeting wrote:
| 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.
| throwanem wrote:
| ...because it added package.json support?
| haolez wrote:
| 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 wrote:
| You don't need an import map on an existing project now,
| meaning it needs less configuration than before.
| ravenstine wrote:
| 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 wrote:
| They were useful for getting URLs out of your source
| code, which are inherently brittle.
| ravenstine wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| This doesn't take into account how much tooling is not
| written in JS. There are lots of ecosystem tools
| implemented in rust, C++, bash, python, etc. that parse
| dependencies for things like CVE checking, version
| bumping, dependency graph analysis, etc. that don't want
| to have to implement a full JS runtime to get the list of
| deps. Python has requirements.txt and pyproject.toml,
| Rust has config.toml, etc. many languages keep their
| project metadata and dependencies in config formats
| instead of code for good reasons.
| ravenstine wrote:
| Why would you need a full JS runtime just to analyze what
| URLs are being imported? You don't even need a _runtime_
| for that. All that 's necessary is to parse the AST, and
| in that case you don't even need an AST parser with full
| language support. It might not be as trivial for other
| language communities as writing a JSON parser, but it's
| not insurmountable or an unreasonable burden.
|
| Honestly, I think the argument that one language
| community should lessen itself for the sake of another
| really bites. Using one language to analyze the
| dependencies of another really isn't a garden variety
| task. In the off chance someone really doesn't want to
| use JavaScript as their primary language for that task,
| what's so bad about calling an external runtime or parser
| from their language of choice?
|
| I'm not saying I'm against import maps, because I think
| it's absolutely reasonable to want the features it
| provides, but I'm not being sold on any argument that
| they're necessary for almost anything. There's not a type
| of application I can think of that can't be written
| without anything an import map does.
| throwingrocks wrote:
| Not sure what's more impressive. You holding out for years for
| this feature or Deno's implementation.
| nikisweeting wrote:
| 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.
| [deleted]
| LniSggDer wrote:
| [dead]
| seumars wrote:
| All the recent Node-related features are bound to alienate their
| core audience but I wonder to what extent.
| llanowarelves wrote:
| The solution to this is socially-enforced, like it is for most
| questions of best practices, code style, etc.
| beebeepka wrote:
| What are the drawbacks of these changes? I haven't been
| following deno very closely.
| teg4n_ wrote:
| 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.
| CuriouslyC wrote:
| 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.
| postalrat wrote:
| Is package.json required?
| imbnwa wrote:
| Not required, but perhaps contagious
| nikisweeting wrote:
| 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.
___________________________________________________________________
(page generated 2023-02-24 23:01 UTC)