13 ms·

JSR: The JavaScript Registry

245 points by slymax 3y ago

slymax 3y ago
The Deno announcement post of their new JavaScript registry: https://deno.com/blog/jsr_open_beta https://deno.com/blog/jsr_open_beta
kwhinnery 3y ago
Kevin from the Deno team here - happy to answer any questions you have today!
- lloydatkinson 3y ago
  I’m curious what this means in regards to this existing “use Deno to also publish to npm” workflow (https://deno.com/blog/dnt-oak https://deno.com/blog/dnt-oak) which I was considering using, and then the JSR announcement happened. The thing I like about the blog post and the mentioned dnt tool is it takes care of lots of bullshit you otherwise need to figure out when publishing to npm. What is the relationship between JSR and DNT in this case? Should one be used over the other? Together? If I want to publish a module so it’s available for Deno and NPM, what is the recommended approach now?
  - kwhinnery 3y ago
    As JSR develops, you can expect to see more features like those of dnt start to show up in the npm compatibility layer. We've also been exploring how to create a good DX around simultaneously publishing JSR modules to npm, so publishers can control their namespace there as well. We definitely know it's a usage pattern folks are interested in. In the immediate term, dnt is still a very strong choice for people that want to develop modules in TypeScript using Deno, and then publish them to npm. In the fullness of time, I expect that JSR will provide a pretty complete solution to this problem as well.
- warpech 3y ago
  I am not a user of Deno, but I acknowledged that HTTPS module imports were one of the original selling points of Deno compared to Node/NPM. Was it revised at some point that a package repository is needed? What's the back story?
  - kwhinnery 3y ago
    HTTPS imports will continue to work and be supported in Deno. However, as we observed their usage in the wild, a couple problems became clear: 1.) Duplicated dependencies - projects would often download multiple versions of the same dependency, because there was no deduplication happening based on semantic versions. 2.) Disappearing dependencies - under some circumstances, an HTTPS import URL would be unavailable, causing code dependent on these modules to break. A central package repository could solve for both of these problems. We considered (and very nearly chose) to just use npm, but it introduced functional and UX problems we wanted to solve for users. So we set about building JSR, and did so in a way that wasn't tightly coupled to Deno (JSR didn't need to be - it is useful in the context of any JavaScript runtime).
    - jarodreyes 3y ago
      This is a solid reason to build it. Makes sense to me.
    - lakpan 3y ago
      > a couple problems became clear: 1.) Duplicated dependencies I’m sorry but that did not come up when designing the system? It’s the whole principle of semver ranges that deno decided to do away with. I cannot believe nobody saw this as a drawback. It’s the first thing I thought when I saw hardcoded versions.
  - wesleytodd 3y ago
    In case you are not aware (maybe you are) node has experimental support for http imports. I personally think this feature is a disaster for many reasons, but if you want to use it in your toy apps it is there in node.
  - 3y ago
imbnwa 3y ago
Man, if only they'd debuted with this, but, hindsight and all. My only thing is that TypeScript has no spec, standard, or competing implementations so it seems a bit risky to treat it as a first-class citizen as far as publishing packages goes.
- lucacasonato 3y ago
  The TypeScript syntax is very stable - there is no spec, but it's very stable. The type system on the other hand: not very stable, and yeah I agree - that would be risky to rely on. However as JSR only relies on the syntax, not on the type system, it's no problem :)
  - imbnwa 3y ago
    Is not the 'slow types' problem[0] a type system dependency, or am I missing something? [0]https://jsr.io/docs/about-slow-types https://jsr.io/docs/about-slow-types
    - lucacasonato 3y ago
      It does not use TSC / do type analysis. This is purely syntax analysis. The "slow types" restriction specifically exists because JSR does not use TSC or do type analysis :)
      - imbnwa 3y ago
        Ah, I see
- usrusr 3y ago
  Consumers don't touch any ts, outside the (technically optional) .d.ts Thecwayvi understand it in theory, the typescript version a library uses could disappear forever the day after a library had been published to JSR and all would be fine. Until someone wants to maintain the code of course, but then you'd have the exact same problem with the elusive typescript version if the repository only took compile output. What JSR would break (or make a deliberately difficult path?) is using some private fork of typescript that isn't even available on the day of publication. The benefit of JSR, as far as I understand it, is offering an easy path to publication that makes type parts not an extra that some might skip but a reliable default. It does make me wonder however, how long-term reliable the finding will be: JSR promises more service than registries before, while also being more tool agnostic. I'm not sure if it's true, but my impression was that in many cases, the registry was primarily bankrolled by however the tooling was funded, e.g. effectively becoming a marketing expense to selling tooling expertise. JSR appears particularly removed from any of that and it's bad enough when the repository fades away in terms of static hosting, it's worse if it also leaves your library without a build process.
franky47 3y ago
I get their stance on TypeScript "exported types must be explicit and not use inference", but I feel like this is going to cause a lot of friction in adoption.
- lucacasonato 3y ago
  1. You can bypass slow types checks during publishing. You will just get a lower JSR score. 2. TypeScript is shipping features in the next release (TS 5.5) has quick-fixes in the editor to make it super easy to add explicit types :) The TS feature is called `isolatedDeclarations`
  - dragomirtitian 3y ago
    I would just like to add some of my findings around the developer friction with isolated declarations. The whole reason isolated declarations is taking so long is because we also worry about making the requirements of this too onerous. To this end with isolated declarations, you do have to specify most types, but not all. For expression where we can reasonably infer the type from local context, we do so. This should ease some of the developer friction. Not all of it. Some things will not be inferrable, but things like primitive types, object literals, tuples will be so it should make it easier. We also worked on a code fixer that adds explicit type annotations where this new flag would raise an error, again to help people migrate if they choose to do so.
- dsherret 3y ago
  To be clear for people reading wondering what this is about, this is only a hard recommendation for the public API types. The reason for it, is by adding explicit types to the boundary of your package, the package becomes way faster for users to type check because every user's machine doesn't need to do all the inference work and type check internal types or packages not related to the types. Additionally, it makes the published code more resilient to changes to TypeScript's inference in the future because it's not doing inference. It also becomes way easier to generate documentation for the package (also, the ability to generate .d.ts or bundled .d.ts files without a type checker becomes easier). Right now, the publish command errors and asks you to fix the issues or bypass it entirely via `--allow-slow-types`. In the future there will be a `--fix` flag to write the explicit types for you.
dazhbog 3y ago
Glad the pinnacle of programming is still there: left-pad
- vdfs 3y ago
  The entire source code: export function leftPad(str, len, ch) { return new Array(len - str.length).fill(ch || ch === 0 ? ch : ' ').join('') + str }
  - winrid 3y ago
    that actually seems really inefficient, it could avoid the array allocation and fill call by just moving the length check...
    - lucacasonato 3y ago
      You could also just use `String.prototype.padStart()` [1], and you get a nice optimized C++ implementation :D [1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/padStart https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
      - usrusr 3y ago
        Pass, not a Rust implementation /s
        randomdata 3y ago
        Is it even AI scale if not performed on the GPU?
        itslennysfault 3y ago
        No, you're right. The White House says no more C/C++ it's your civic duty.
      - diggan 3y ago
evbogue 3y ago
Can JSR also be used as a CDN for browser module imports?
- kwhinnery 3y ago
  Not yet, but esm.sh mentions they have experimental support now to check out: https://twitter.com/jexia_/status/1762516242626416750 https://twitter.com/jexia_/status/1762516242626416750
grose 3y ago
What's the best way to include a binary blob (wasm binary) in your package? For NPM I've been using a bundler (esbuild's `binary` loader) but I'm not sure of the best way to do that in a modern, jsr-friendly way.
- alex_suzuki 3y ago
  If you‘re using emscripten, check out the SINGLE_FILE option, that embeds the WASM as a base64-encoded string into the JS.
- lucacasonato 3y ago
  We will soon support WASM imports (`import source foo from "./foo.wasm"`). [1] [1]: https://github.com/tc39/proposal-source-phase-imports https://github.com/tc39/proposal-source-phase-imports
  - grose 3y ago
    Excellent, this will make my life easier. Thanks!
h43z 3y ago
Everything just has to sound cool these days because yolo yarn dlx jsr add @oak/oak
- kwhinnery 3y ago
  That does get to be a mouthful! But if you wanted, you can of course do: yarn global add jsr so that subsequent installs could just be: jsr add @oak/oak
  - joshmanders 3y ago
    I still find `npm install @oak/oak` better.
MatthiasPortzel 3y ago
> JSR isn't a replacement for the npm registry; it's a superset of npm. I first read this line to mean that JSR contains every package on NPM, and was just doing some post-processing on them. But it does seem to be its own registry. Maybe the intent of the line was to communicate that you can install packages from both?
- kwhinnery 3y ago
  I think this is mostly right - "superset" in that JSR modules can depend on npm modules, and projects using npm can use the npm registry and JSR together. The bottom line we'd want to communicate is that JSR is additive to npm, and the two can be used at the same time.
  - tumetab1 3y ago
    The usage of the "superset" expression is very confusing to me and I bet to many others. I would recommend to use other terms such as "Additive" or "Complementary" to describe JSR.
  - nerdponx 3y ago
    That's not really what "superset" means, so I think you might want to change the wording.
  - grodriguez100 3y ago
    > I think this is mostly right - "superset" in that JSR modules can depend on npm modules This is not what most people would think when a registry is said to be a “superset” of another.
  - lakpan 3y ago
    JSR is almost literally a subset of npm in features. Npm allows publishing of anything, JSR only actual TS/ESM. Whether those modules have dependencies doesn’t expand the set IMHO
vlakreeh 3y ago
One thing I'm not sure about when reading their policy is what'll happen in another kik situation. If someone were to claim the scope Microsoft (for example) that had no relation to Microsoft and then Microsoft came along and wanted the scope what would happen? If MS got the scope what would happen to the packages in that scope, or if MS didn't get it what is done to clearly communicate that this is an unofficial account (presumably) asking on MS' behalf? In this early on period I'd expect a lot of people to claim the scopes of notable companies and these companies might take issue with that if they choose to use jsr down the line.
- kwhinnery 3y ago
  We do intend to take a more editorial approach to scopes, and assign scopes to users in a way we think is more intuitive for end users of JSR. We have reserved some obvious scope names already, but in the future, we'd likely entertain requests to reassign ownership of scopes for the benefit of the broader user community (as in the case of a brand owner requesting ownership of their brand name). So in the case that a user published "@cocacola/foo", previously published versions of "@cocacola/foo" would remain available indefinitely (unless they were found to be malicious), but we would likely be willing to assign ownership of the "@cocacola" scope to a representative from that brand/company if they asked for it and we could verify their identity. The original author of "@cocacola/foo" would need to publish the module going forward under a different scope.
  - hjadal 3y ago
    In the example of "@cocacola/foo" would it allow for the "@cocacola/foo" package to be updated with new versions by the new owners? Or would the foo package essentially be archived and read-only from this point on?
    - kwhinnery 3y ago
      The new scope owner would be able to update "@cocacola/foo" and publish new versions (previous versions would be unaffected).
  - 3y ago
tentacleuno 3y ago
This is great! I very much like the added TypeScript support (which the standard NPM registry does not have.) and that it's open-source. I'll see about getting my packages uploaded onto here, too -- just having built-in support for TypeScript makes packaging x100 easier. Regarding NPM, it's absolutely insane that we've been depending upon a closed-source, monolithic nightmare with poor UX for so long. You can't even use comments in package.json -- overall, it feels like a holdover we haven't figured out how to replace. Furthermore, it's scary that Microsoft, through GitHub, now hold so much power over the JavaScript industry -- enshittification will most likely ensue.
- seniorsassycat 3y ago
  I'm not sure jsr fixes comments in package.json, and I wouldn't blame npm for the miss feature. package.json is used at runtime by node.js and strictly parsed as json. Npm or just could strip comments on publish, but local development of the package would break. Not sure if bun or demo use pjson at runtime or if they allow comments. I think it's interesting that JavaScript projects at the package root despite most projects compiling to dist nowadays. I'd like tool to generate the whole package root, including a transpiled or generated package.json
  - mhagemeister 3y ago
    > I'd like tool to generate the whole package root, including a transpiled or generated package.json That's exactly what JSR does. We generate the package.json ourselves.
    - seniorsassycat 3y ago
      In development, or on publish?
  - tentacleuno 3y ago
    > package.json is used at runtime by node.js and strictly parsed as json It still constitutes an unfriendly developer experience -- people have had to make workarounds to document what complicated scripts do, and why they use certain dependencies, etc. I understand how JSON.parse works, but this still isn't the best behaviour. Note that this is just one example of unfriendly UX in NPM as a whole -- this isn't the hill I'm dying on, so to speak, I'm just giving an example of how I believe the industry is being held back by tools which just haven't kept up with demand.
Pet_Ant 3y ago
This is a terrible name. JSR already stands for "Java Specification Request" which is basically an RFC or standard for Java (not JavaScript). This is going to make Google searches even more difficult. Searching for Java jobs and getting JavaScript jobs is already bad enough. This name is just making a big mess with semantic name collision in our mental namespaces. Just make it "RfJS" maybe for "Registry for JavaScript" (if that doesn't class). I know Firefox had a few naming rounds going through Phoenix and Firebird IIRC first. No opinion on the actual project itself.
- lolinder 3y ago
  JSR is also a company that produces synthetic rubber, a semiconductors company, a pharma company, a journal, and a company that produces merch for rock musicians. All of these rank higher on Google for JSR than Java Specification Requests. Given that you're going to have a hard time pulling up the JSR you're looking for without adding qualifiers anyway, I don't think this name choice is going to substantially change anything.
wiseowise 3y ago
> JSR isn't a replacement for the npm registry Shame.
diggan 3y ago
> JSR: The JavaScript Registry Then on the website: > Made for TypeScript & ESM > JSR is designed for TypeScript > You publish TypeScript source Seems the <title> tag needs an update to reflect what this really is :)
- itslennysfault 3y ago
  and the name... I suggested TSR (the TypeScript Registry)
- tomalbrc 3y ago
  The project is called "The JavaScript Registry" > The JavaScript Registry (JSR) is a modern package registry for JavaScript and TypeScript. https://jsr.io/docs/introduction https://jsr.io/docs/introduction
  - diggan 3y ago
    Yeah, this is what I'm complaining about. If you're building something that is designed for TypeScript, made for TypeScript and publishes TypeScript sources, then I find it really hard to understand why you'd name it "The JavaScript Registry".
    - Vinnl 3y ago
      Presumably because they don't want to imply that it won't work if you don't use TypeScript.
      - seniorsassycat 3y ago
        I don't think it will, unless you use the npm compatibility layer.
        Vinnl 3y ago
        An npm compatibility layer doesn't sound like it has anything to do with TypeScript? I'm assuming that you can use JavaScript anywhere you can also use TypeScript.
apitman 3y ago
Seeing Bun/Node/Deno support reminds me of a question: are there any good resources on writing JS that works in all 3 and the browser? For example if I wanted to write a simple filesystem API that would work the same across bunodeno?
- selfmodruntime 3y ago
  You can't, and for good reason. Deno has slightly different API's than Node. Bun also has subtle differences between their STL implementation and Node's, but afaik, they're getting there.
  - apitman 3y ago
    I think maybe I was unclear. I'm talking about writing libraries that abstract across these differences and provide a single API, as sibling describes. I already know it's possible. I made a simple filesystem abstraction here[0] and a very simple HTTP library that uses it here[1]. They both work in Node/Deno and the browser. Unfortunately I ran into issues with Bun's slice implementation[2], but that should be fixed eventually. My overall question is that I suspect there's a much better way of detecting and using the different backends, and I'm wondering what techniques are out there. [0]: https://github.com/waygate-io/fs-js https://github.com/waygate-io/fs-js [1]: https://github.com/waygate-io/http-js https://github.com/waygate-io/http-js [2]: https://github.com/oven-sh/bun/issues/7057 https://github.com/oven-sh/bun/issues/7057
- TheFuzzball 3y ago
  I think you'd have to write a facade package with a consistent API that mapped to the node/deno/bun equivalents, since they're each quite different. Best bet is to use the Node fs package and rely on the deno/bun compatibility layer. More generally, Deno pushes for Web Platform APIs, and as more are proposed and implemented the runtime-specific APIs will become fewer and fewer.
  - apitman 3y ago
    Yeah this is basically what I'm trying to do (see response to sibling). Unfortunately I consider Node's APIs the worst of the 3. No shade on them it's just an older design. I really like Deno's approach since my code also needs to work in the browser. Writing HTTP handlers that take Request[0] and return Response[1] is a beautiful bit of symmetry with frontend code and feels like cheating. [0]: https://developer.mozilla.org/en-US/docs/Web/API/Request https://developer.mozilla.org/en-US/docs/Web/API/Request [1]: https://developer.mozilla.org/en-US/docs/Web/API/Response https://developer.mozilla.org/en-US/docs/Web/API/Response
jayrwren 3y ago
if it is made for typescript, shouldn't it be tsr?
laluneodyssee 3y ago
Not to sound overly critical but what value is Featured Packages | New Packages etc...?
- lucacasonato 3y ago
  PRs welcome: https://github.com/jsr-io/jsr https://github.com/jsr-io/jsr
xalava 3y ago
_ s
m3h 3y ago
As a long-time front-end developer, I'm not seeing a strong value proposition here to justify the further fragmentation another package registry is going to cause. > You publish TypeScript source, and JSR handles generating API docs, .d.ts files, and transpiling your code for cross-runtime compatibility. This sounds like another building service I don't control. There's already too much magic in publishing transpiled TypeScript packages but at least the current tools let me control exactly what artifacts get pushed out. > web-standard ECMAScript modules The "web standard" part is meaningless considering that most production websites will bundle the files together as part of their build/optimization process for size and loading speed, leaving only a giant chunk(s) that resembles nothing like the original ES modules. > JSR isn't a replacement for the npm registry; it's a superset of npm. A super of npm means that the packages created for this repository will not work in the npm ecosystem. What is this if not a "replacement" of the npm registry and further fragmentation of the JS ecosystem? >JSR modules can be used with any JavaScript package manager, and in any project with a node_modules folder. This makes the already complicated module resolution logic in most bundler/packaging tools even more complicated as they must account for the intricacies of another package manager. A house of cards being stacked on another house of cards... > Module authors can count on great editor support from strongly typed modules, without the need to transpile and distribute typings manually. The website seems to insist that distributing typings is a complicated process when it is just the .d.ts files bundled with the published package and an additional entry in the package.json file. > Easy publishing with a single command - the CLI will walk you through the rest It seems like every benefit that this project offers can be fixed in the current ecosystem by better client-side tooling that enforces standards during the publishing process while keeping full backward compatibility with over a decade of packages published and without fragmenting the ecosystem.
- m3h 3y ago
  Another comment in the thread makes a very good point: > Man, if only they'd debuted with this, but, hindsight and all. My only thing is that TypeScript has no spec, standard, or competing implementations so it seems a bit risky to treat it as a first-class citizen as far as publishing packages goes. Add to that the frequent compilation issues that happen as TypeScript adds or removes types in the global imports, changes language conventions, and updates compilation checks whenever a new version gets released.
toastercat 3y ago
Kind of jarring now that the standard library documentation on the Deno website just redirects to JSR. Speaking of which, the new deno.com site looks like a marketing website designed by an AI. Lacks all of the pragmatic unix-y character that Deno originally had, and is just filled with meaningless numbers and metrics and way too much blank space. It's like they're selling a product... which I guess is what Deno is now. VC funding will do that to you.
- sureglymop 3y ago
  I hate modern day landing pages. Even those single page websites where some animation plays while scrolling down were more interesting.
fhd2 3y ago
Oh boy. Reading the title ("JSR: The JavaScript Registry" at the time of writing) I had high hopes this might be what I'm looking for: Dependency management for JavaScript in the browser. It's something entirely different. I tried to look for something lately that: 1. Makes it easy to download specified versions of JS libs. 2. Exposes these libs as proper ES6 modules. I get why (2) is a bit tricky, it'd be fantastic but more of a nice to have anyway. I don't really get why there's no popular tool for (1) yet. Sure, I can just fetch the files I want from a CDN and commit them to a vendor directory, or I can write a little script that downloads them from a CDN. Or hey, I can fetch frontend dependencies via NPM and have a script that builds/copies the stuff. But that's a bit much labour for something that I thought would be a relatively common requirement. Am I in the minority to occasionally want to build web apps _without_ bundlers? Being able to skip the build step is very powerful both for keeping things simple and turnaround times fast, IMHO.
- chaorace 3y ago
  esm.sh is a decent solution for this. It's not totally ideal... but it'll turn NPM modules into ES6-compatible URLs no problem.
  - fhd2 3y ago
    Oooh, esm.sh looks pretty close to what I'm looking for, thanks!
- lucacasonato 3y ago
  > Exposes these libs as proper ES6 modules. We don't do this natively (yet?), but esm.sh supports JSR alreay: https://twitter.com/jexia_/status/1762516242626416750 https://twitter.com/jexia_/status/1762516242626416750
  - fhd2 3y ago
    Thanks for pointing this out!
- WorldMaker 3y ago
hamuraijack 3y ago
Obligatory xkcd reference. https://xkcd.com/927/ https://xkcd.com/927/
seabass 3y ago
When would I want to use JSR? The "Why JSR?" section simply says JSR is a superset of NPM that can be used with any javascript package manager. But NPM itself can also be used with any javascript package manager as far as I know. It seems like the benefit they're trying to add is strict type support for packages, but the fact that it's a superset of NPM means all existing packages that lack types are still supported by JSR. So, what benefit is so great that it's worth segmenting the ecosystem? Side rant: not at all a fan of the decision to punish libraries ("slow types") that use type inference by reducing their score.
- apitman 3y ago
  > not at all a fan of the decision to punish libraries ("slow types") that use type inference by reducing their score. Do you feel that using type inference doesn't actually reduce performance, or just that it's not a big enough problem to warrant a reduced score?
  - lakpan 3y ago
    Type inference in dependencies does not reduce performance for users, but just for JSR. Here they’re going “the Google way” by adding some random metric that benefits them, not users. Once generated, .d.ts files do not contain inference.
  - mhagemeister 3y ago
    The performance of type inference matters for runtimes which work with TypeScript files directly, rather then using the transpiled .js + .d.ts files like Deno. This has several benefits in that we can jump to the source on "go to definition" rather than some random .d.ts file among other things. Deno uses the original TS files for type checking as well and that's why inference also affects type checking performance in some runtimes. By ensuring explicit return types in the public API, the generation of .d.ts files is turned into a mere syntax transform, rather than requiring the tsc compiler. This is something TypeScript will ship with in the next release itself. They're adding a new `isolatedDeclarations` option which is the same thing.
- kwhinnery 3y ago
deleted 3y ago
[deleted]
jmull 3y ago
After reading the "Why JSR?" article I still don't understand why this exists. It looks like it has a few niceties but also some limitations. To catch on you need to convince some significant segment of both package publishers and consumers to switch to it. That means there needs to be some killer feature they just can't get with the existing registries, and I'm not seeing anything like that.
- throwitaway1123 3y ago
  > After reading the "Why JSR?" article I still don't understand why this exists The cynical answer: they realized it's actually advantageous to have a centralized package registry instead of importing from random urls, and as a for-profit VC backed company they'd rather not have their entire ecosystem depend on the Microsoft-owned NPM. The optimistic answer: having a second registry makes the entire JS/TS ecosystem less fragile by not having a single point of failure.
darepublic 3y ago
One solution to the package dependency swamp is to make a project with little to no dependencies? I'm rambling but I would curious to experiment with an approach where, when I needed a bit of code to solve a problem the "package manager" (more like code procurer) would just find a snippet of code I need, perhaps reference it's origin, perhaps add related unit tests and then I would copy paste it into my own code base.
- cumwolf 3y ago
  i think this could function in a small project scenario and i like the idea. Don't think that would be super maintainable in larger enterprise applications. You'd essentially be on the hook for maintaining more code as well.
- apitman 3y ago
  I've experimented[0] with something along these lines. The basic idea is that it's desirable to be able to reuse snippets/functions across projects, but you shouldn't need to go full left-pad. So basically you run tuplates.py on your project, it goes through all files and any line comment that includes "tuplate_start(URI)" it goes out and fetches the URI (local filesystem or HTTP supported), and replaces everything until it finds a line comment with "tuplate_end". Nice thing is it enables basic templating in any language, and instead of checking templates into source control, you're committing working code. Also combines really nicely with jsdelivr where you can import specific versions of files directly from GitHub. [0]: https://github.com/anderspitman/tuplates https://github.com/anderspitman/tuplates
feross 3y ago
Our team at Socket (disclosure: I'm the founder) wrote up an excellent overview of JSR and everything we know so far about it here: https://socket.dev/blog/jsr-new-javascript-package-registry https://socket.dev/blog/jsr-new-javascript-package-registry
- Technetium 3y ago
  I can't even tell that I'm blocking anything, but: "You are offline. This site requires an internet connection."
addtej 3y ago
I didn't understand the purpose of this even after browsing the site.
msoad 3y ago
The server that takes your TypeScript and does all of the work to publish a nice package on npm is great. But why wouldn't they publish to npm after that? Why make a new registry that is introducing fragmentation?
wdb 3y ago
I am not sure what the value of this. It's having a subset of the npmjs registry as it's only for ESM-only packages. If you want to use ESM modules on a website in a commercial setting; the security team will demand you host on a CDN under your own control etc. It's fun for personal projects?
lenerdenator 3y ago
Heard about it on Syntax podcast. There is nothing wrong with JS-based development that can be fixed by _more_ ways to do the same thing, even if it adds a few new neat tricks.
foresto 3y ago
JSR must be firmly embedded into my memory, because all I see is a 6502 assembly instruction. :) https://en.wikipedia.org/wiki/MOS_Technology_6502#Instruction_table https://en.wikipedia.org/wiki/MOS_Technology_6502#Instructio...
smusamashah 3y ago
Is there a similar site but for browser only javascript libraries? I am not a web developer, and always find NPM etc way too much for my occasional needs. When I search internet for anything, 90% of the times I get an NPM based library that can not work in browser with just a <script src="lib.js">. JavaScript has improved a lot and does not really need Node/compilation steps for almost all my use cases. Is there anything where I can search for browser only, client side javascript libs?
- toastercat 3y ago
  You can usually browse npm for what you need, and when you want to use it, look at unpkg.com/<name of package> Usually this will give you a .min.js file ready for you to script include on your site, for example, unpkg.com/mithril Sometimes library authors don't default the export to a browser ready minified version or ESM module, in which case, you can snoop around the built package at unpkg.com/browse/mithril/. Most READMEs worth a damn should tell you how to use their libraries without npm if possible. Unfortunately, a lot of library authors suck.
  - joshstrange 3y ago
    > Unfortunately, a lot of library authors suck. The nerve of them not catering to the small percentage of use cases for a project they often do in their free time and often for free. The entitlement is real.
    - toastercat 3y ago
      Sorry I forgot we're not allowed to criticize open-source maintainers ever. But as a library author myself, it takes less than 10 seconds to add such a section in my README.
  - lakpan 3y ago
    Unpkg just serves the raw files, which may contain require() calls or import from other npm packages. That won’t work. The closest service is https://esm.sh https://esm.sh, but you can’t download from it.
reactordev 3y ago
I know this is a nit and not the responsibility of jsr (looks great all! Good job! Can’t wait to use it) but the fact that we still have a “node_modules” folder as a standard for the ecosystem. This sucks. I get it. I know why. Node is king. However there are other runtimes out there that use this pattern simply because they don’t want to reinvent a package management system (I’m with them on this) but have to use “node_modules” as their module folder simply for compatibility. I decided not to follow suit and use @modules instead. :P I like JSR, and this in no way reflects my opinion of js,ts,jsr, or you all. I just think it’s time to move on from some dahl-isms (decisions made while getting node production ready).
skybrian 3y ago
Looks good to me. Lots of nice fixes. Unfortunately, it seems we’re stuck with semver, because that’s a package manager thing and not a registry thing. Better use a lockfile. Edit: another issue is that when I tried to sign up, in the GitHub auth page, it asks for “act on my behalf” permission. No thanks.
- jakubmazanec 3y ago
  I think SemVer is a good thing. What do you mean by "we're stuck" with it?
  - skybrian 3y ago
    For dependencies where you didn’t explicitly specify the exact version, taking the latest version is nondeterministic - it varies over time. Someone else who checks out your code will get different results. I was hoping for something like Go’s minimum version dependency resolution. A lock file does solve the immediate issue.
    - lakpan 3y ago
      > Someone else who checks out your code will get different results. > I was hoping for something like Go’s minimum version dependency resolution. Uh and that’s different how? The default semver range is “minimum dependency version” with an upper bound in the current major.
      - skybrian 3y ago
        The upper bound resolves to a different version after a new minor version is published. That’s nondeterministic. Someone else checking out your project will get different results, unless you use a lock file.
        lakpan 3y ago
        See, you don’t know how npm works. Npm does not care about the lockfile of dependencies. “Someone checking out my project” always gets the latest version of each dependency within the semver range, until their lockfile locks a version into place.
prossercj 3y ago
Looks like just another example of https://xkcd.com/927/ https://xkcd.com/927/

245 points by slymax 3y ago

The Deno announcement post of their new JavaScript registry: https://deno.com/blog/jsr_open_beta https://deno.com/blog/jsr_open_beta

kwhinnery 3y ago

Kevin from the Deno team here - happy to answer any questions you have today!

lloydatkinson 3y ago
I’m curious what this means in regards to this existing “use Deno to also publish to npm” workflow (https://deno.com/blog/dnt-oak https://deno.com/blog/dnt-oak) which I was considering using, and then the JSR announcement happened. The thing I like about the blog post and the mentioned dnt tool is it takes care of lots of bullshit you otherwise need to figure out when publishing to npm. What is the relationship between JSR and DNT in this case? Should one be used over the other? Together? If I want to publish a module so it’s available for Deno and NPM, what is the recommended approach now?
- kwhinnery 3y ago
  As JSR develops, you can expect to see more features like those of dnt start to show up in the npm compatibility layer. We've also been exploring how to create a good DX around simultaneously publishing JSR modules to npm, so publishers can control their namespace there as well. We definitely know it's a usage pattern folks are interested in. In the immediate term, dnt is still a very strong choice for people that want to develop modules in TypeScript using Deno, and then publish them to npm. In the fullness of time, I expect that JSR will provide a pretty complete solution to this problem as well.
warpech 3y ago
I am not a user of Deno, but I acknowledged that HTTPS module imports were one of the original selling points of Deno compared to Node/NPM. Was it revised at some point that a package repository is needed? What's the back story?
- kwhinnery 3y ago
  HTTPS imports will continue to work and be supported in Deno. However, as we observed their usage in the wild, a couple problems became clear: 1.) Duplicated dependencies - projects would often download multiple versions of the same dependency, because there was no deduplication happening based on semantic versions. 2.) Disappearing dependencies - under some circumstances, an HTTPS import URL would be unavailable, causing code dependent on these modules to break. A central package repository could solve for both of these problems. We considered (and very nearly chose) to just use npm, but it introduced functional and UX problems we wanted to solve for users. So we set about building JSR, and did so in a way that wasn't tightly coupled to Deno (JSR didn't need to be - it is useful in the context of any JavaScript runtime).
  - jarodreyes 3y ago
    This is a solid reason to build it. Makes sense to me.
  - lakpan 3y ago
    > a couple problems became clear: 1.) Duplicated dependencies I’m sorry but that did not come up when designing the system? It’s the whole principle of semver ranges that deno decided to do away with. I cannot believe nobody saw this as a drawback. It’s the first thing I thought when I saw hardcoded versions.
- wesleytodd 3y ago
  In case you are not aware (maybe you are) node has experimental support for http imports. I personally think this feature is a disaster for many reasons, but if you want to use it in your toy apps it is there in node.
- 3y ago

imbnwa 3y ago

Man, if only they'd debuted with this, but, hindsight and all. My only thing is that TypeScript has no spec, standard, or competing implementations so it seems a bit risky to treat it as a first-class citizen as far as publishing packages goes.

lucacasonato 3y ago
The TypeScript syntax is very stable - there is no spec, but it's very stable. The type system on the other hand: not very stable, and yeah I agree - that would be risky to rely on. However as JSR only relies on the syntax, not on the type system, it's no problem :)
- imbnwa 3y ago
  Is not the 'slow types' problem[0] a type system dependency, or am I missing something? [0]https://jsr.io/docs/about-slow-types https://jsr.io/docs/about-slow-types
  - lucacasonato 3y ago
    It does not use TSC / do type analysis. This is purely syntax analysis. The "slow types" restriction specifically exists because JSR does not use TSC or do type analysis :)
    - imbnwa 3y ago
      Ah, I see
usrusr 3y ago
Consumers don't touch any ts, outside the (technically optional) .d.ts Thecwayvi understand it in theory, the typescript version a library uses could disappear forever the day after a library had been published to JSR and all would be fine. Until someone wants to maintain the code of course, but then you'd have the exact same problem with the elusive typescript version if the repository only took compile output. What JSR would break (or make a deliberately difficult path?) is using some private fork of typescript that isn't even available on the day of publication. The benefit of JSR, as far as I understand it, is offering an easy path to publication that makes type parts not an extra that some might skip but a reliable default. It does make me wonder however, how long-term reliable the finding will be: JSR promises more service than registries before, while also being more tool agnostic. I'm not sure if it's true, but my impression was that in many cases, the registry was primarily bankrolled by however the tooling was funded, e.g. effectively becoming a marketing expense to selling tooling expertise. JSR appears particularly removed from any of that and it's bad enough when the repository fades away in terms of static hosting, it's worse if it also leaves your library without a build process.

franky47 3y ago

I get their stance on TypeScript "exported types must be explicit and not use inference", but I feel like this is going to cause a lot of friction in adoption.

lucacasonato 3y ago
1. You can bypass slow types checks during publishing. You will just get a lower JSR score. 2. TypeScript is shipping features in the next release (TS 5.5) has quick-fixes in the editor to make it super easy to add explicit types :) The TS feature is called `isolatedDeclarations`
- dragomirtitian 3y ago
  I would just like to add some of my findings around the developer friction with isolated declarations. The whole reason isolated declarations is taking so long is because we also worry about making the requirements of this too onerous. To this end with isolated declarations, you do have to specify most types, but not all. For expression where we can reasonably infer the type from local context, we do so. This should ease some of the developer friction. Not all of it. Some things will not be inferrable, but things like primitive types, object literals, tuples will be so it should make it easier. We also worked on a code fixer that adds explicit type annotations where this new flag would raise an error, again to help people migrate if they choose to do so.
dsherret 3y ago
To be clear for people reading wondering what this is about, this is only a hard recommendation for the public API types. The reason for it, is by adding explicit types to the boundary of your package, the package becomes way faster for users to type check because every user's machine doesn't need to do all the inference work and type check internal types or packages not related to the types. Additionally, it makes the published code more resilient to changes to TypeScript's inference in the future because it's not doing inference. It also becomes way easier to generate documentation for the package (also, the ability to generate .d.ts or bundled .d.ts files without a type checker becomes easier). Right now, the publish command errors and asks you to fix the issues or bypass it entirely via `--allow-slow-types`. In the future there will be a `--fix` flag to write the explicit types for you.

dazhbog 3y ago

Glad the pinnacle of programming is still there: left-pad

vdfs 3y ago
The entire source code: export function leftPad(str, len, ch) { return new Array(len - str.length).fill(ch || ch === 0 ? ch : ' ').join('') + str }
- winrid 3y ago
  that actually seems really inefficient, it could avoid the array allocation and fill call by just moving the length check...
  - lucacasonato 3y ago
    You could also just use `String.prototype.padStart()` [1], and you get a nice optimized C++ implementation :D [1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/padStart https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
    - usrusr 3y ago
      Pass, not a Rust implementation /s
      - randomdata 3y ago
        Is it even AI scale if not performed on the GPU?
      - itslennysfault 3y ago
        No, you're right. The White House says no more C/C++ it's your civic duty.
    - diggan 3y ago

evbogue 3y ago

Can JSR also be used as a CDN for browser module imports?

kwhinnery 3y ago
Not yet, but esm.sh mentions they have experimental support now to check out: https://twitter.com/jexia_/status/1762516242626416750 https://twitter.com/jexia_/status/1762516242626416750

grose 3y ago

What's the best way to include a binary blob (wasm binary) in your package? For NPM I've been using a bundler (esbuild's `binary` loader) but I'm not sure of the best way to do that in a modern, jsr-friendly way.

alex_suzuki 3y ago
If you‘re using emscripten, check out the SINGLE_FILE option, that embeds the WASM as a base64-encoded string into the JS.
lucacasonato 3y ago
We will soon support WASM imports (`import source foo from "./foo.wasm"`). [1] [1]: https://github.com/tc39/proposal-source-phase-imports https://github.com/tc39/proposal-source-phase-imports
- grose 3y ago
  Excellent, this will make my life easier. Thanks!

h43z 3y ago

Everything just has to sound cool these days because yolo yarn dlx jsr add @oak/oak

kwhinnery 3y ago
That does get to be a mouthful! But if you wanted, you can of course do: yarn global add jsr so that subsequent installs could just be: jsr add @oak/oak
- joshmanders 3y ago
  I still find `npm install @oak/oak` better.

MatthiasPortzel 3y ago

> JSR isn't a replacement for the npm registry; it's a superset of npm. I first read this line to mean that JSR contains every package on NPM, and was just doing some post-processing on them. But it does seem to be its own registry. Maybe the intent of the line was to communicate that you can install packages from both?

kwhinnery 3y ago
I think this is mostly right - "superset" in that JSR modules can depend on npm modules, and projects using npm can use the npm registry and JSR together. The bottom line we'd want to communicate is that JSR is additive to npm, and the two can be used at the same time.
- tumetab1 3y ago
  The usage of the "superset" expression is very confusing to me and I bet to many others. I would recommend to use other terms such as "Additive" or "Complementary" to describe JSR.
- nerdponx 3y ago
  That's not really what "superset" means, so I think you might want to change the wording.
- grodriguez100 3y ago
  > I think this is mostly right - "superset" in that JSR modules can depend on npm modules This is not what most people would think when a registry is said to be a “superset” of another.
- lakpan 3y ago
  JSR is almost literally a subset of npm in features. Npm allows publishing of anything, JSR only actual TS/ESM. Whether those modules have dependencies doesn’t expand the set IMHO

vlakreeh 3y ago

One thing I'm not sure about when reading their policy is what'll happen in another kik situation. If someone were to claim the scope Microsoft (for example) that had no relation to Microsoft and then Microsoft came along and wanted the scope what would happen? If MS got the scope what would happen to the packages in that scope, or if MS didn't get it what is done to clearly communicate that this is an unofficial account (presumably) asking on MS' behalf? In this early on period I'd expect a lot of people to claim the scopes of notable companies and these companies might take issue with that if they choose to use jsr down the line.

kwhinnery 3y ago
We do intend to take a more editorial approach to scopes, and assign scopes to users in a way we think is more intuitive for end users of JSR. We have reserved some obvious scope names already, but in the future, we'd likely entertain requests to reassign ownership of scopes for the benefit of the broader user community (as in the case of a brand owner requesting ownership of their brand name). So in the case that a user published "@cocacola/foo", previously published versions of "@cocacola/foo" would remain available indefinitely (unless they were found to be malicious), but we would likely be willing to assign ownership of the "@cocacola" scope to a representative from that brand/company if they asked for it and we could verify their identity. The original author of "@cocacola/foo" would need to publish the module going forward under a different scope.
- hjadal 3y ago
  In the example of "@cocacola/foo" would it allow for the "@cocacola/foo" package to be updated with new versions by the new owners? Or would the foo package essentially be archived and read-only from this point on?
  - kwhinnery 3y ago
    The new scope owner would be able to update "@cocacola/foo" and publish new versions (previous versions would be unaffected).
- 3y ago

tentacleuno 3y ago

This is great! I very much like the added TypeScript support (which the standard NPM registry does not have.) and that it's open-source. I'll see about getting my packages uploaded onto here, too -- just having built-in support for TypeScript makes packaging x100 easier. Regarding NPM, it's absolutely insane that we've been depending upon a closed-source, monolithic nightmare with poor UX for so long. You can't even use comments in package.json -- overall, it feels like a holdover we haven't figured out how to replace. Furthermore, it's scary that Microsoft, through GitHub, now hold so much power over the JavaScript industry -- enshittification will most likely ensue.

seniorsassycat 3y ago
I'm not sure jsr fixes comments in package.json, and I wouldn't blame npm for the miss feature. package.json is used at runtime by node.js and strictly parsed as json. Npm or just could strip comments on publish, but local development of the package would break. Not sure if bun or demo use pjson at runtime or if they allow comments. I think it's interesting that JavaScript projects at the package root despite most projects compiling to dist nowadays. I'd like tool to generate the whole package root, including a transpiled or generated package.json
- mhagemeister 3y ago
  > I'd like tool to generate the whole package root, including a transpiled or generated package.json That's exactly what JSR does. We generate the package.json ourselves.
  - seniorsassycat 3y ago
    In development, or on publish?
- tentacleuno 3y ago
  > package.json is used at runtime by node.js and strictly parsed as json It still constitutes an unfriendly developer experience -- people have had to make workarounds to document what complicated scripts do, and why they use certain dependencies, etc. I understand how JSON.parse works, but this still isn't the best behaviour. Note that this is just one example of unfriendly UX in NPM as a whole -- this isn't the hill I'm dying on, so to speak, I'm just giving an example of how I believe the industry is being held back by tools which just haven't kept up with demand.

Pet_Ant 3y ago

This is a terrible name. JSR already stands for "Java Specification Request" which is basically an RFC or standard for Java (not JavaScript). This is going to make Google searches even more difficult. Searching for Java jobs and getting JavaScript jobs is already bad enough. This name is just making a big mess with semantic name collision in our mental namespaces. Just make it "RfJS" maybe for "Registry for JavaScript" (if that doesn't class). I know Firefox had a few naming rounds going through Phoenix and Firebird IIRC first. No opinion on the actual project itself.

lolinder 3y ago
JSR is also a company that produces synthetic rubber, a semiconductors company, a pharma company, a journal, and a company that produces merch for rock musicians. All of these rank higher on Google for JSR than Java Specification Requests. Given that you're going to have a hard time pulling up the JSR you're looking for without adding qualifiers anyway, I don't think this name choice is going to substantially change anything.

wiseowise 3y ago

> JSR isn't a replacement for the npm registry Shame.

diggan 3y ago

> JSR: The JavaScript Registry Then on the website: > Made for TypeScript & ESM > JSR is designed for TypeScript > You publish TypeScript source Seems the <title> tag needs an update to reflect what this really is :)

itslennysfault 3y ago
and the name... I suggested TSR (the TypeScript Registry)
tomalbrc 3y ago
The project is called "The JavaScript Registry" > The JavaScript Registry (JSR) is a modern package registry for JavaScript and TypeScript. https://jsr.io/docs/introduction https://jsr.io/docs/introduction
- diggan 3y ago
  Yeah, this is what I'm complaining about. If you're building something that is designed for TypeScript, made for TypeScript and publishes TypeScript sources, then I find it really hard to understand why you'd name it "The JavaScript Registry".
  - Vinnl 3y ago
    Presumably because they don't want to imply that it won't work if you don't use TypeScript.
    - seniorsassycat 3y ago
      I don't think it will, unless you use the npm compatibility layer.
      - Vinnl 3y ago
        An npm compatibility layer doesn't sound like it has anything to do with TypeScript? I'm assuming that you can use JavaScript anywhere you can also use TypeScript.

apitman 3y ago

Seeing Bun/Node/Deno support reminds me of a question: are there any good resources on writing JS that works in all 3 and the browser? For example if I wanted to write a simple filesystem API that would work the same across bunodeno?

selfmodruntime 3y ago
You can't, and for good reason. Deno has slightly different API's than Node. Bun also has subtle differences between their STL implementation and Node's, but afaik, they're getting there.
- apitman 3y ago
  I think maybe I was unclear. I'm talking about writing libraries that abstract across these differences and provide a single API, as sibling describes. I already know it's possible. I made a simple filesystem abstraction here[0] and a very simple HTTP library that uses it here[1]. They both work in Node/Deno and the browser. Unfortunately I ran into issues with Bun's slice implementation[2], but that should be fixed eventually. My overall question is that I suspect there's a much better way of detecting and using the different backends, and I'm wondering what techniques are out there. [0]: https://github.com/waygate-io/fs-js https://github.com/waygate-io/fs-js [1]: https://github.com/waygate-io/http-js https://github.com/waygate-io/http-js [2]: https://github.com/oven-sh/bun/issues/7057 https://github.com/oven-sh/bun/issues/7057
TheFuzzball 3y ago
I think you'd have to write a facade package with a consistent API that mapped to the node/deno/bun equivalents, since they're each quite different. Best bet is to use the Node fs package and rely on the deno/bun compatibility layer. More generally, Deno pushes for Web Platform APIs, and as more are proposed and implemented the runtime-specific APIs will become fewer and fewer.
- apitman 3y ago
  Yeah this is basically what I'm trying to do (see response to sibling). Unfortunately I consider Node's APIs the worst of the 3. No shade on them it's just an older design. I really like Deno's approach since my code also needs to work in the browser. Writing HTTP handlers that take Request[0] and return Response[1] is a beautiful bit of symmetry with frontend code and feels like cheating. [0]: https://developer.mozilla.org/en-US/docs/Web/API/Request https://developer.mozilla.org/en-US/docs/Web/API/Request [1]: https://developer.mozilla.org/en-US/docs/Web/API/Response https://developer.mozilla.org/en-US/docs/Web/API/Response

jayrwren 3y ago

if it is made for typescript, shouldn't it be tsr?

laluneodyssee 3y ago

Not to sound overly critical but what value is Featured Packages | New Packages etc...?

lucacasonato 3y ago
PRs welcome: https://github.com/jsr-io/jsr https://github.com/jsr-io/jsr

xalava 3y ago

_ s

m3h 3y ago

As a long-time front-end developer, I'm not seeing a strong value proposition here to justify the further fragmentation another package registry is going to cause. > You publish TypeScript source, and JSR handles generating API docs, .d.ts files, and transpiling your code for cross-runtime compatibility. This sounds like another building service I don't control. There's already too much magic in publishing transpiled TypeScript packages but at least the current tools let me control exactly what artifacts get pushed out. > web-standard ECMAScript modules The "web standard" part is meaningless considering that most production websites will bundle the files together as part of their build/optimization process for size and loading speed, leaving only a giant chunk(s) that resembles nothing like the original ES modules. > JSR isn't a replacement for the npm registry; it's a superset of npm. A super of npm means that the packages created for this repository will not work in the npm ecosystem. What is this if not a "replacement" of the npm registry and further fragmentation of the JS ecosystem? >JSR modules can be used with any JavaScript package manager, and in any project with a node_modules folder. This makes the already complicated module resolution logic in most bundler/packaging tools even more complicated as they must account for the intricacies of another package manager. A house of cards being stacked on another house of cards... > Module authors can count on great editor support from strongly typed modules, without the need to transpile and distribute typings manually. The website seems to insist that distributing typings is a complicated process when it is just the .d.ts files bundled with the published package and an additional entry in the package.json file. > Easy publishing with a single command - the CLI will walk you through the rest It seems like every benefit that this project offers can be fixed in the current ecosystem by better client-side tooling that enforces standards during the publishing process while keeping full backward compatibility with over a decade of packages published and without fragmenting the ecosystem.

m3h 3y ago
Another comment in the thread makes a very good point: > Man, if only they'd debuted with this, but, hindsight and all. My only thing is that TypeScript has no spec, standard, or competing implementations so it seems a bit risky to treat it as a first-class citizen as far as publishing packages goes. Add to that the frequent compilation issues that happen as TypeScript adds or removes types in the global imports, changes language conventions, and updates compilation checks whenever a new version gets released.

toastercat 3y ago

Kind of jarring now that the standard library documentation on the Deno website just redirects to JSR. Speaking of which, the new deno.com site looks like a marketing website designed by an AI. Lacks all of the pragmatic unix-y character that Deno originally had, and is just filled with meaningless numbers and metrics and way too much blank space. It's like they're selling a product... which I guess is what Deno is now. VC funding will do that to you.

sureglymop 3y ago
I hate modern day landing pages. Even those single page websites where some animation plays while scrolling down were more interesting.

fhd2 3y ago

Oh boy. Reading the title ("JSR: The JavaScript Registry" at the time of writing) I had high hopes this might be what I'm looking for: Dependency management for JavaScript in the browser. It's something entirely different. I tried to look for something lately that: 1. Makes it easy to download specified versions of JS libs. 2. Exposes these libs as proper ES6 modules. I get why (2) is a bit tricky, it'd be fantastic but more of a nice to have anyway. I don't really get why there's no popular tool for (1) yet. Sure, I can just fetch the files I want from a CDN and commit them to a vendor directory, or I can write a little script that downloads them from a CDN. Or hey, I can fetch frontend dependencies via NPM and have a script that builds/copies the stuff. But that's a bit much labour for something that I thought would be a relatively common requirement. Am I in the minority to occasionally want to build web apps _without_ bundlers? Being able to skip the build step is very powerful both for keeping things simple and turnaround times fast, IMHO.

chaorace 3y ago
esm.sh is a decent solution for this. It's not totally ideal... but it'll turn NPM modules into ES6-compatible URLs no problem.
- fhd2 3y ago
  Oooh, esm.sh looks pretty close to what I'm looking for, thanks!
lucacasonato 3y ago
> Exposes these libs as proper ES6 modules. We don't do this natively (yet?), but esm.sh supports JSR alreay: https://twitter.com/jexia_/status/1762516242626416750 https://twitter.com/jexia_/status/1762516242626416750
- fhd2 3y ago
  Thanks for pointing this out!
WorldMaker 3y ago

hamuraijack 3y ago

Obligatory xkcd reference. https://xkcd.com/927/ https://xkcd.com/927/

seabass 3y ago

When would I want to use JSR? The "Why JSR?" section simply says JSR is a superset of NPM that can be used with any javascript package manager. But NPM itself can also be used with any javascript package manager as far as I know. It seems like the benefit they're trying to add is strict type support for packages, but the fact that it's a superset of NPM means all existing packages that lack types are still supported by JSR. So, what benefit is so great that it's worth segmenting the ecosystem? Side rant: not at all a fan of the decision to punish libraries ("slow types") that use type inference by reducing their score.

apitman 3y ago
> not at all a fan of the decision to punish libraries ("slow types") that use type inference by reducing their score. Do you feel that using type inference doesn't actually reduce performance, or just that it's not a big enough problem to warrant a reduced score?
- lakpan 3y ago
  Type inference in dependencies does not reduce performance for users, but just for JSR. Here they’re going “the Google way” by adding some random metric that benefits them, not users. Once generated, .d.ts files do not contain inference.
- mhagemeister 3y ago
  The performance of type inference matters for runtimes which work with TypeScript files directly, rather then using the transpiled .js + .d.ts files like Deno. This has several benefits in that we can jump to the source on "go to definition" rather than some random .d.ts file among other things. Deno uses the original TS files for type checking as well and that's why inference also affects type checking performance in some runtimes. By ensuring explicit return types in the public API, the generation of .d.ts files is turned into a mere syntax transform, rather than requiring the tsc compiler. This is something TypeScript will ship with in the next release itself. They're adding a new `isolatedDeclarations` option which is the same thing.
kwhinnery 3y ago

deleted 3y ago

[deleted]

jmull 3y ago

After reading the "Why JSR?" article I still don't understand why this exists. It looks like it has a few niceties but also some limitations. To catch on you need to convince some significant segment of both package publishers and consumers to switch to it. That means there needs to be some killer feature they just can't get with the existing registries, and I'm not seeing anything like that.

throwitaway1123 3y ago
> After reading the "Why JSR?" article I still don't understand why this exists The cynical answer: they realized it's actually advantageous to have a centralized package registry instead of importing from random urls, and as a for-profit VC backed company they'd rather not have their entire ecosystem depend on the Microsoft-owned NPM. The optimistic answer: having a second registry makes the entire JS/TS ecosystem less fragile by not having a single point of failure.

darepublic 3y ago

One solution to the package dependency swamp is to make a project with little to no dependencies? I'm rambling but I would curious to experiment with an approach where, when I needed a bit of code to solve a problem the "package manager" (more like code procurer) would just find a snippet of code I need, perhaps reference it's origin, perhaps add related unit tests and then I would copy paste it into my own code base.

cumwolf 3y ago
i think this could function in a small project scenario and i like the idea. Don't think that would be super maintainable in larger enterprise applications. You'd essentially be on the hook for maintaining more code as well.
apitman 3y ago
I've experimented[0] with something along these lines. The basic idea is that it's desirable to be able to reuse snippets/functions across projects, but you shouldn't need to go full left-pad. So basically you run tuplates.py on your project, it goes through all files and any line comment that includes "tuplate_start(URI)" it goes out and fetches the URI (local filesystem or HTTP supported), and replaces everything until it finds a line comment with "tuplate_end". Nice thing is it enables basic templating in any language, and instead of checking templates into source control, you're committing working code. Also combines really nicely with jsdelivr where you can import specific versions of files directly from GitHub. [0]: https://github.com/anderspitman/tuplates https://github.com/anderspitman/tuplates

feross 3y ago

Our team at Socket (disclosure: I'm the founder) wrote up an excellent overview of JSR and everything we know so far about it here: https://socket.dev/blog/jsr-new-javascript-package-registry https://socket.dev/blog/jsr-new-javascript-package-registry

Technetium 3y ago
I can't even tell that I'm blocking anything, but: "You are offline. This site requires an internet connection."

addtej 3y ago

I didn't understand the purpose of this even after browsing the site.

msoad 3y ago

The server that takes your TypeScript and does all of the work to publish a nice package on npm is great. But why wouldn't they publish to npm after that? Why make a new registry that is introducing fragmentation?

wdb 3y ago

I am not sure what the value of this. It's having a subset of the npmjs registry as it's only for ESM-only packages. If you want to use ESM modules on a website in a commercial setting; the security team will demand you host on a CDN under your own control etc. It's fun for personal projects?

lenerdenator 3y ago

Heard about it on Syntax podcast. There is nothing wrong with JS-based development that can be fixed by _more_ ways to do the same thing, even if it adds a few new neat tricks.

foresto 3y ago

JSR must be firmly embedded into my memory, because all I see is a 6502 assembly instruction. :) https://en.wikipedia.org/wiki/MOS_Technology_6502#Instruction_table https://en.wikipedia.org/wiki/MOS_Technology_6502#Instructio...

smusamashah 3y ago

Is there a similar site but for browser only javascript libraries? I am not a web developer, and always find NPM etc way too much for my occasional needs. When I search internet for anything, 90% of the times I get an NPM based library that can not work in browser with just a <script src="lib.js">. JavaScript has improved a lot and does not really need Node/compilation steps for almost all my use cases. Is there anything where I can search for browser only, client side javascript libs?

toastercat 3y ago
You can usually browse npm for what you need, and when you want to use it, look at unpkg.com/<name of package> Usually this will give you a .min.js file ready for you to script include on your site, for example, unpkg.com/mithril Sometimes library authors don't default the export to a browser ready minified version or ESM module, in which case, you can snoop around the built package at unpkg.com/browse/mithril/. Most READMEs worth a damn should tell you how to use their libraries without npm if possible. Unfortunately, a lot of library authors suck.
- joshstrange 3y ago
  > Unfortunately, a lot of library authors suck. The nerve of them not catering to the small percentage of use cases for a project they often do in their free time and often for free. The entitlement is real.
  - toastercat 3y ago
    Sorry I forgot we're not allowed to criticize open-source maintainers ever. But as a library author myself, it takes less than 10 seconds to add such a section in my README.
- lakpan 3y ago
  Unpkg just serves the raw files, which may contain require() calls or import from other npm packages. That won’t work. The closest service is https://esm.sh https://esm.sh, but you can’t download from it.

reactordev 3y ago

I know this is a nit and not the responsibility of jsr (looks great all! Good job! Can’t wait to use it) but the fact that we still have a “node_modules” folder as a standard for the ecosystem. This sucks. I get it. I know why. Node is king. However there are other runtimes out there that use this pattern simply because they don’t want to reinvent a package management system (I’m with them on this) but have to use “node_modules” as their module folder simply for compatibility. I decided not to follow suit and use @modules instead. :P I like JSR, and this in no way reflects my opinion of js,ts,jsr, or you all. I just think it’s time to move on from some dahl-isms (decisions made while getting node production ready).

skybrian 3y ago

Looks good to me. Lots of nice fixes. Unfortunately, it seems we’re stuck with semver, because that’s a package manager thing and not a registry thing. Better use a lockfile. Edit: another issue is that when I tried to sign up, in the GitHub auth page, it asks for “act on my behalf” permission. No thanks.

jakubmazanec 3y ago
I think SemVer is a good thing. What do you mean by "we're stuck" with it?
- skybrian 3y ago
  For dependencies where you didn’t explicitly specify the exact version, taking the latest version is nondeterministic - it varies over time. Someone else who checks out your code will get different results. I was hoping for something like Go’s minimum version dependency resolution. A lock file does solve the immediate issue.
  - lakpan 3y ago
    > Someone else who checks out your code will get different results. > I was hoping for something like Go’s minimum version dependency resolution. Uh and that’s different how? The default semver range is “minimum dependency version” with an upper bound in the current major.
    - skybrian 3y ago
      The upper bound resolves to a different version after a new minor version is published. That’s nondeterministic. Someone else checking out your project will get different results, unless you use a lock file.
      - lakpan 3y ago
        See, you don’t know how npm works. Npm does not care about the lockfile of dependencies. “Someone checking out my project” always gets the latest version of each dependency within the semver range, until their lockfile locks a version into place.

prossercj 3y ago

Looks like just another example of https://xkcd.com/927/ https://xkcd.com/927/