10 ms·

JSR first impressions: a JavaScript package manager by the Deno team (2023)

92 points by satvikpendem 3y ago

diob 3y ago
That font is so hard for me to read, personally. Had to swap it in the browser tools.
- SOLAR_FIELDS 3y ago
  Op should also probably consider running future posts through a spell checker. There were quite a few obvious misspellings and words that I had to double take on because they were the completely wrong word to use in that context and some other word should have been used instead
- MBCook 3y ago
  The heavy emphasis on “deno.land/x” every single time it appeared was kind of puzzling too, I found it quite distracting compared to the rest of the text.
  - saghm 3y ago
    I think that's just how all of the links are styled?
- binary132 3y ago
  Comic Sans would be preferable.
issafram 3y ago
Another one?
- MBCook 3y ago
  If you would read the article, they’re coming to replace the registry as well instead of being a new developer front end npm, yarn, etc) against the same npmjs registry everyone is used to.
  - monkpit 3y ago
    The HN title says “package manager” but that’s nowhere in the article, so it’s a bit confusing for sure.
    - MBCook 3y ago
      It’s the 4th paragraph. First sentence. Right under the heading “What is JSR”.
      - tekacs 3y ago
        I mean yes... but the sentence clearly says that it's /not/ a package manager. > JSR is a Javascript/TypeScript registry. It is not a package manager.
    - simultsop 3y ago
      Probably someone else and not OP, posted it here... Hence the confusion.
streptomycin 3y ago
Deno continues to seem very interested in making marginal improvements to the Node/npm ecosystem that (if adopted) would be massive breaking changes for everyone. It's hard for me to imagine many people being interested in this.
- moritzwarhier 3y ago
  Sadly, this is well-put. Now that I got used to pnpm and yarn, as well as monorepo tools (nx), I feel like my preference would be to continue improving npm and node without forking. I mean, there's yarn, pnpm and other package managers. Then there's alternate JS runtimes, e.g. Deno or Bun. Both of which are primarily interesting to me because of first-class TS support without transpiling. I feel that the ideas of all these same-but-different approaches are in dire need of a shared roof and efforts on standardization and interoperability. Not sure if corepack[1] is a step in the right direction, because it basically adds another abstraction layer on top of the runtime to choose and install the package manager... All of the mentioned tools bring laudable and serious effort to the table, but I'd love for convergence to happen as soon as possible. ^1 https://nodejs.org/api/corepack.html https://nodejs.org/api/corepack.html
  - teaearlgraycold 3y ago
    Bun is actually attempting to achieve full NodeJS interoperability. Side note: nx is some of the worst software I've ever been unfortunate enough to use. Maybe it's changed in the last 2 years.
    - moritzwarhier 3y ago
      Thanks, I didn't know this. Re nx, i can't tell if it has improved since 2 years ago, but i feel it being an inconvenient abstract layer at times; OTOH: I rarely encountered nx-specific issues at work, and all of them have been caching-related. It's mostly doing well at organizing a monorepo with lots of code in different languages.
    - basicallybones 3y ago
tracker1 3y ago
I'm a bit mixed in this. I get the desire to be interpretable with npm. There's a massive ecosystem out there. I kind of liked the everything is a fixed http endpoint. I also get the desire for compatible versions across need dependencies. I have access, but haven't worked with it yet since my personal time has been spent more on rust recently. Should probably convert one of my libraries to Deno first and see where the pain points are both with jsr and deploying to npm as well as checking npm compatibility. A lot of what I've worked on has been feature complete and only updating dependencies now and then. So rolling into Deno testing and formatting could be interesting. I've been using Rome/Biome for a lot of this the past couple years. TS/Deno first is definitely easier than the other way. I've also found Deno to be great for shell scripting.
fyrn_ 3y ago
Package manager is clearly an incorrect title (issue is on the hn submission side), should be "package registry" package managers are a dime a dozen these days.
spankalee 3y ago
Publishing and importing TypeScript is a huge mistake. Packages should just compile TypeScript to JS and publish that as they do now.
- paulgb 3y ago
  Why? I’m not primarily a JS/TS dev, but when I’m dealing with the JS ecosystem, operating across two languages is one of the pain points (e.g. clicking a function in my editor and getting the typedef instead of the code). Now that runtimes like Deno and Bun support TS natively, why shouldn’t we avoid that completely?
  - usrusr 3y ago
    Perspective from another not primarily js/ts dev: in this context, js is the equivalent of a .jar full of .class files. Instead of a -sources.jar you'd have a sourcemap. The original typescript would be more like a repository dump, and chances are the build depends heavily on an exotic fork of python or something equally unexpected.
    - paulgb 3y ago
      I get the analogy, but I don’t see what this actually solves in the JS/TS case. The jvm can’t run Java source files directly and needs a build step, so to the extent that the build step is not portable, it makes sense to ship the built version. Jars are also used for dynamic imports where doing the build at runtime would be expensive. By comparison, runtimes like Deno can run TS directly now. There is no separate build step required. After all, it’s a scripting language! The fact that it has a compile step at all is just baggage at this point.
      - usrusr 3y ago
        Can run one specific version of TS, and JS that has been compiled from any version of TS. That ability might be very valuable for the development loop, but it cannot be intended for dependencies because source compatibility is very low in the priorities list of TS. In JVM words: where scala seems to have given up on cross-version compatibility of the complied code, forcing cross building upon library authors and dependency registries but succeeds in sufficient source compatibility to enable that cross building, TS, due to being bound to baseline JS as output anyways, does the inverse. The output works across versions (how could it not, when it's meant to work across languages), but with that a given it can take its liberties with input (source) compatibility.
whoknowsidont 3y ago
TypeScript should not be pushed or published. Do not do that.
- Bellend 3y ago
  Could you provide why not? I have a utility library (Project A) and whilst messing around with TurboRepo, I noticed I could point to the source files in my package. I haven't progressed down that route, but something about it seemed nice. So in other words, if Project B depends on Project A, either I could build Project A and then build Project B or I could just build Project B (which consumes Project A as a typescript package). Kinda confusingly written but I would love to know why that is an issue.
  - afavour 3y ago
    One thing that comes to mind is different TypeScript versions. JS has ES6 and ES2020 etc and that’s enough to deal with, Typescript is younger and has been moving faster, compatibility might be difficult around the edges. Longer term I agree with you though, I’d much rather see TS source than JS plus types when I’m looking at the source code of a module.
    - ricardobeat 3y ago
      I don’t know why you’re being downvoted, my experience has been that minor version TS releases usually create a cascade of hundreds of type check failures even though the syntax itself is backwards-compatible. It would be impossible for a project pulling TS sources directly to achieve stability (or even compile all dependencies with a single version of TypeScript in the first place).
      - dsherret 3y ago
        In Deno with JSR, only the public API gets used for type checking because publishing enforces that the public API can be determined without type inference. So it's similar to declaration files (d.ts files) and you wouldn't see errors that occur at the non-declaration level unless someone explicitly opted out of those publishing checks (which is heavily discouraged).
seniorsassycat 3y ago
I think there's a lot of room to innovate in the JavaScript package manager and registry space. • support for optional features and dependencies tied to them, ala cargo. How many npm vulnerabilities are introduced thru the command line parser of a package you only use as a library? • step away from packag.json. It's fine to keep it for the registry or even runtime, but development should use a file that supports comments. • some automated version compatibility enforcement via typedefs or registry side tests. • packages with more than one artifact so types, original source, and platform native artifacts can be published in one package but download only when needed.
- bandergirl 3y ago
  • that’s a solved problem: packages shouldn’t bundle CLI tools. Sindre Sorhus has been separating “CLI” from “API” for many years. “Unused dependencies” in general isn’t a solvable problem because a dependency might only be used if a certain parameter is passed. By the time that piece of code is reached, you either have it installed or it’s too late. • that’s an issue that never got solved for the same reason: “package.json is never going away so we won’t add more ways to do the same thing” — ok so node/npm is going to suck forever, fantastic.
  - seniorsassycat 3y ago
    I think feature dependencies are better modeled than simple package splitting. > For example, let’s say we have added some serialization support to our library, and it requires enabling a corresponding feature > In this example, enabling the serde feature will enable the serde dependency. It will also enable the serde feature for the rgb dependency, but only if something else has enabled the rgb dependency. https://doc.rust-lang.org/cargo/reference/features.html https://doc.rust-lang.org/cargo/reference/features.html It sounds better to install foo { features = serde } than foo, @foo/serde, and @bar/serde.
  - seniorsassycat 3y ago
    Npm has optional dependencies and there are libraries that error when you use a code push that requires them. Features would formalize that pattern and improve it with clear errors, and composability.
deleted 3y ago
[deleted]
deleted 3y ago
[deleted]
dgoldstein0 3y ago
Anyone know what the "zapped" they mention as a form of typechecking is? I'd like to learn more about that and the tools that do that
- emi2k01 3y ago
  https://github.com/denoland/deno_graph/blob/main/src/fast_check/mod.rs https://github.com/denoland/deno_graph/blob/main/src/fast_ch... You can search for "no_zap" under the `denoland` org if you want to have a bit more context. I believe it's a form of type checking where, simplifying, things like function bodies are removed and type checking is only done across top-level items.
- dsherret 3y ago
  It's being renamed to a no-slow-types lint rule that occurs on publish and in deno lint. Essentially it enforces that the types of the public API can be determined without inference. This enables a few things: 1. Type checking ts sources is really fast when Deno determines a package does not use slow types. It may entirely drop packages and modules that aren't relevant for type checking. It also skips parsing and building symbols for the internals of a package (ex. function bodies). 2. Documentation is really fast to generate (doesn't need a type checker). 3. A corresponding .d.ts file for relevant typescript code is automatically created for Node.
simultsop 3y ago
Usually it is hard to understand the underlying design, I guess all intentions and plans are not well communicated or they are held private perhaps for monetization or other purposes. I would hope to see some support, at least from everyone ever used node or npm. It is the same author who created node at first, obviously the team is trying to innovate, from angles we probably have no vision. Like many other resources this one would also be optional for you to use or not. I am very happy how the many options are shaping up and getting perfected in their ways. Looking forward for the future excitingly.
mark_and_sweep 3y ago
I feel like SEO might be problematic initially given that JSR is already an abbreviation for a Japanese corporation and Java Specification Requests. See https://en.m.wikipedia.org/wiki/JSR https://en.m.wikipedia.org/wiki/JSR

92 points by satvikpendem 3y ago

diob 3y ago

That font is so hard for me to read, personally. Had to swap it in the browser tools.

SOLAR_FIELDS 3y ago
Op should also probably consider running future posts through a spell checker. There were quite a few obvious misspellings and words that I had to double take on because they were the completely wrong word to use in that context and some other word should have been used instead
MBCook 3y ago
The heavy emphasis on “deno.land/x” every single time it appeared was kind of puzzling too, I found it quite distracting compared to the rest of the text.
- saghm 3y ago
  I think that's just how all of the links are styled?
binary132 3y ago
Comic Sans would be preferable.

issafram 3y ago

Another one?

MBCook 3y ago
If you would read the article, they’re coming to replace the registry as well instead of being a new developer front end npm, yarn, etc) against the same npmjs registry everyone is used to.
- monkpit 3y ago
  The HN title says “package manager” but that’s nowhere in the article, so it’s a bit confusing for sure.
  - MBCook 3y ago
    It’s the 4th paragraph. First sentence. Right under the heading “What is JSR”.
    - tekacs 3y ago
      I mean yes... but the sentence clearly says that it's /not/ a package manager. > JSR is a Javascript/TypeScript registry. It is not a package manager.
  - simultsop 3y ago
    Probably someone else and not OP, posted it here... Hence the confusion.

streptomycin 3y ago

Deno continues to seem very interested in making marginal improvements to the Node/npm ecosystem that (if adopted) would be massive breaking changes for everyone. It's hard for me to imagine many people being interested in this.

moritzwarhier 3y ago
Sadly, this is well-put. Now that I got used to pnpm and yarn, as well as monorepo tools (nx), I feel like my preference would be to continue improving npm and node without forking. I mean, there's yarn, pnpm and other package managers. Then there's alternate JS runtimes, e.g. Deno or Bun. Both of which are primarily interesting to me because of first-class TS support without transpiling. I feel that the ideas of all these same-but-different approaches are in dire need of a shared roof and efforts on standardization and interoperability. Not sure if corepack[1] is a step in the right direction, because it basically adds another abstraction layer on top of the runtime to choose and install the package manager... All of the mentioned tools bring laudable and serious effort to the table, but I'd love for convergence to happen as soon as possible. ^1 https://nodejs.org/api/corepack.html https://nodejs.org/api/corepack.html
- teaearlgraycold 3y ago
  Bun is actually attempting to achieve full NodeJS interoperability. Side note: nx is some of the worst software I've ever been unfortunate enough to use. Maybe it's changed in the last 2 years.
  - moritzwarhier 3y ago
    Thanks, I didn't know this. Re nx, i can't tell if it has improved since 2 years ago, but i feel it being an inconvenient abstract layer at times; OTOH: I rarely encountered nx-specific issues at work, and all of them have been caching-related. It's mostly doing well at organizing a monorepo with lots of code in different languages.
  - basicallybones 3y ago

tracker1 3y ago

I'm a bit mixed in this. I get the desire to be interpretable with npm. There's a massive ecosystem out there. I kind of liked the everything is a fixed http endpoint. I also get the desire for compatible versions across need dependencies. I have access, but haven't worked with it yet since my personal time has been spent more on rust recently. Should probably convert one of my libraries to Deno first and see where the pain points are both with jsr and deploying to npm as well as checking npm compatibility. A lot of what I've worked on has been feature complete and only updating dependencies now and then. So rolling into Deno testing and formatting could be interesting. I've been using Rome/Biome for a lot of this the past couple years. TS/Deno first is definitely easier than the other way. I've also found Deno to be great for shell scripting.

fyrn_ 3y ago

Package manager is clearly an incorrect title (issue is on the hn submission side), should be "package registry" package managers are a dime a dozen these days.

spankalee 3y ago

Publishing and importing TypeScript is a huge mistake. Packages should just compile TypeScript to JS and publish that as they do now.

paulgb 3y ago
Why? I’m not primarily a JS/TS dev, but when I’m dealing with the JS ecosystem, operating across two languages is one of the pain points (e.g. clicking a function in my editor and getting the typedef instead of the code). Now that runtimes like Deno and Bun support TS natively, why shouldn’t we avoid that completely?
- usrusr 3y ago
  Perspective from another not primarily js/ts dev: in this context, js is the equivalent of a .jar full of .class files. Instead of a -sources.jar you'd have a sourcemap. The original typescript would be more like a repository dump, and chances are the build depends heavily on an exotic fork of python or something equally unexpected.
  - paulgb 3y ago
    I get the analogy, but I don’t see what this actually solves in the JS/TS case. The jvm can’t run Java source files directly and needs a build step, so to the extent that the build step is not portable, it makes sense to ship the built version. Jars are also used for dynamic imports where doing the build at runtime would be expensive. By comparison, runtimes like Deno can run TS directly now. There is no separate build step required. After all, it’s a scripting language! The fact that it has a compile step at all is just baggage at this point.
    - usrusr 3y ago
      Can run one specific version of TS, and JS that has been compiled from any version of TS. That ability might be very valuable for the development loop, but it cannot be intended for dependencies because source compatibility is very low in the priorities list of TS. In JVM words: where scala seems to have given up on cross-version compatibility of the complied code, forcing cross building upon library authors and dependency registries but succeeds in sufficient source compatibility to enable that cross building, TS, due to being bound to baseline JS as output anyways, does the inverse. The output works across versions (how could it not, when it's meant to work across languages), but with that a given it can take its liberties with input (source) compatibility.

whoknowsidont 3y ago

TypeScript should not be pushed or published. Do not do that.

Bellend 3y ago
Could you provide why not? I have a utility library (Project A) and whilst messing around with TurboRepo, I noticed I could point to the source files in my package. I haven't progressed down that route, but something about it seemed nice. So in other words, if Project B depends on Project A, either I could build Project A and then build Project B or I could just build Project B (which consumes Project A as a typescript package). Kinda confusingly written but I would love to know why that is an issue.
- afavour 3y ago
  One thing that comes to mind is different TypeScript versions. JS has ES6 and ES2020 etc and that’s enough to deal with, Typescript is younger and has been moving faster, compatibility might be difficult around the edges. Longer term I agree with you though, I’d much rather see TS source than JS plus types when I’m looking at the source code of a module.
  - ricardobeat 3y ago
    I don’t know why you’re being downvoted, my experience has been that minor version TS releases usually create a cascade of hundreds of type check failures even though the syntax itself is backwards-compatible. It would be impossible for a project pulling TS sources directly to achieve stability (or even compile all dependencies with a single version of TypeScript in the first place).
    - dsherret 3y ago
      In Deno with JSR, only the public API gets used for type checking because publishing enforces that the public API can be determined without type inference. So it's similar to declaration files (d.ts files) and you wouldn't see errors that occur at the non-declaration level unless someone explicitly opted out of those publishing checks (which is heavily discouraged).

seniorsassycat 3y ago

I think there's a lot of room to innovate in the JavaScript package manager and registry space. • support for optional features and dependencies tied to them, ala cargo. How many npm vulnerabilities are introduced thru the command line parser of a package you only use as a library? • step away from packag.json. It's fine to keep it for the registry or even runtime, but development should use a file that supports comments. • some automated version compatibility enforcement via typedefs or registry side tests. • packages with more than one artifact so types, original source, and platform native artifacts can be published in one package but download only when needed.

bandergirl 3y ago
• that’s a solved problem: packages shouldn’t bundle CLI tools. Sindre Sorhus has been separating “CLI” from “API” for many years. “Unused dependencies” in general isn’t a solvable problem because a dependency might only be used if a certain parameter is passed. By the time that piece of code is reached, you either have it installed or it’s too late. • that’s an issue that never got solved for the same reason: “package.json is never going away so we won’t add more ways to do the same thing” — ok so node/npm is going to suck forever, fantastic.
- seniorsassycat 3y ago
  I think feature dependencies are better modeled than simple package splitting. > For example, let’s say we have added some serialization support to our library, and it requires enabling a corresponding feature > In this example, enabling the serde feature will enable the serde dependency. It will also enable the serde feature for the rgb dependency, but only if something else has enabled the rgb dependency. https://doc.rust-lang.org/cargo/reference/features.html https://doc.rust-lang.org/cargo/reference/features.html It sounds better to install foo { features = serde } than foo, @foo/serde, and @bar/serde.
- seniorsassycat 3y ago
  Npm has optional dependencies and there are libraries that error when you use a code push that requires them. Features would formalize that pattern and improve it with clear errors, and composability.

deleted 3y ago

[deleted]

deleted 3y ago

[deleted]

dgoldstein0 3y ago

Anyone know what the "zapped" they mention as a form of typechecking is? I'd like to learn more about that and the tools that do that

emi2k01 3y ago
https://github.com/denoland/deno_graph/blob/main/src/fast_check/mod.rs https://github.com/denoland/deno_graph/blob/main/src/fast_ch... You can search for "no_zap" under the `denoland` org if you want to have a bit more context. I believe it's a form of type checking where, simplifying, things like function bodies are removed and type checking is only done across top-level items.
dsherret 3y ago
It's being renamed to a no-slow-types lint rule that occurs on publish and in deno lint. Essentially it enforces that the types of the public API can be determined without inference. This enables a few things: 1. Type checking ts sources is really fast when Deno determines a package does not use slow types. It may entirely drop packages and modules that aren't relevant for type checking. It also skips parsing and building symbols for the internals of a package (ex. function bodies). 2. Documentation is really fast to generate (doesn't need a type checker). 3. A corresponding .d.ts file for relevant typescript code is automatically created for Node.

simultsop 3y ago

Usually it is hard to understand the underlying design, I guess all intentions and plans are not well communicated or they are held private perhaps for monetization or other purposes. I would hope to see some support, at least from everyone ever used node or npm. It is the same author who created node at first, obviously the team is trying to innovate, from angles we probably have no vision. Like many other resources this one would also be optional for you to use or not. I am very happy how the many options are shaping up and getting perfected in their ways. Looking forward for the future excitingly.

mark_and_sweep 3y ago

I feel like SEO might be problematic initially given that JSR is already an abbreviation for a Japanese corporation and Java Specification Requests. See https://en.m.wikipedia.org/wiki/JSR https://en.m.wikipedia.org/wiki/JSR