I didn't understand the purpose of this even after browsing the site.
JSR: The JavaScript Registry
101–110 of 183 posts
Re: JSR: The JavaScript Registry
#102> JSR: The JavaScript Registry Then on the website: > Made for TypeScript & ESM > JSR is designed for TypeScript > You publish TypeScript source Seems the tag needs an update to reflect what this really is :)
This is probably a marketing bug on our part. While we did want to design for TypeScript from the outset, you can definitely happily write and publish plain JavaScript code on JSR. We probably need to do a better job explaining and featuring this.
Re: JSR: The JavaScript Registry
#103Earlier quoted context omitted.
Presumably because they don't want to imply that it won't work if you don't use TypeScript.
I don't think it will, unless you use the npm compatibility layer.
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.
Re: JSR: The JavaScript Registry
#104Earlier quoted context omitted.
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…
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?
The new scope owner would be able to update "@cocacola/foo" and publish new versions (previous versions would be unaffected).
Re: JSR: The JavaScript Registry
#105After 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.
> 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.
Re: JSR: The JavaScript Registry
#106Our 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
I can't even tell that I'm blocking anything, but: "You are offline. This site requires an internet connection."
Re: JSR: The JavaScript Registry
#107The 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?
Re: JSR: The JavaScript Registry
#108Earlier quoted context omitted.
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…
> 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 you're basically committing to repeating the Kik drama? For reference: https://en.wikipedia.org/wiki/Kik_Messenger#Open-source_modu... It would be great to find a way of structuring these registries/repositories…
Thankfully JSR won't be capable of a left-pad situation where packages can be unpublished - published packages are immutable[1].
As for the potential for disagreements over whether or not a scope should be transferred, that is a big reason why we want to figure out community involvement in governance sooner rather than later. We are gathering potential volunteers who want to discuss becoming a community moderator - if anyone would be potentially interested, they can sign up to join that conversation[2].
[1] https://jsr.io/docs/immutability [2] https://jsr.io/go/moderator
Re: JSR: The JavaScript Registry
#109I 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?
Re: JSR: The JavaScript Registry
#110One 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…
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.