Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JSR: The JavaScript Registry

jsr.io

Post reply on HN
Print view View original

151–160 of 183 posts

Re: JSR: The JavaScript Registry

#151

Post by notnullorvoid »

lucacasonato wrote: post #122
seniorsassycat wrote: post #90

Earlier quoted context omitted.

I'm really curious how you handle typescript versions and options that affect emit

- `isolatedModules: true` is required - Decorators: standard spec decorators only - JSX: tsconfig options are lifted into JSX pragma comments on publish (configuration goes into code so that consumers can emit based on these options still) TypeScript has very very few options that affect emit, and effectively everyone has settled on one subset now.

> TypeScript has very very few options that affect emit, and effectively everyone has settled on one subset now.

Very confused by this statement. There's lots of options that affect emit. And what do you mean a subset has been settled on? Take any 2 TypeScript projects and I'd wager there's a high chance they have options that emit code differently.

Config aside TS emits .d.ts that is not always backwards compatible with older TS versions. Does jsr support typeVersions for such situations?

Re: JSR: The JavaScript Registry

#152

Post by lakpan »

apitman wrote: post #111
seabass wrote: post #81

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…

> 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?

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.

Re: JSR: The JavaScript Registry

#153

Post by lakpan »

kwhinnery wrote: post #33
MatthiasPortzel wrote: post #27

> 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?

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.

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

Re: JSR: The JavaScript Registry

#154

Post by lakpan »

kwhinnery wrote: post #112
warpech wrote: post #43

Earlier quoted context omitted.

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?

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, ca…

> 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.

Re: JSR: The JavaScript Registry

#155

Post by lakpan »

apitman wrote: post #44

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?

Bun’s goal is to be an actual superset of node, so you can write just for node and expect it to work in bun.

As for deno, I think if you publish ESM you’re mostly covered since deno can install from the npm registry.

Re: JSR: The JavaScript Registry

#156

Post by lakpan »

skybrian wrote: post #143
jakubmazanec wrote: post #141

Earlier quoted context omitted.

I think SemVer is a good thing. What do you mean by "we're stuck" with it?

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.

> 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.

Re: JSR: The JavaScript Registry

#157

Post by lakpan »

vdfs wrote: post #13
dazhbog wrote: post #12

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

The entire source code: export function leftPad(str, len, ch) { return new Array(len - str.length).fill(ch || ch === 0 ? ch : ' ').join('') + str }

I wanna see you write it from memory. Now do it without bugs fixed in 2013 in that package.

Re: JSR: The JavaScript Registry

#158

Post by lakpan »

smusamashah wrote: post #131

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 . 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 sear…

> Is there anything where I can search for browser only

There used to be bower, thankfully that’s now gone.

> JavaScript has improved a lot

So has its ecosystem. Setting up parcel or Vite is straightforward and should get you out of those problems. The time when you could just download a .js file and stick it in your vendors folder is long long gone. Please bundle and minify your files before serving them.

Re: JSR: The JavaScript Registry

#159

Post by lakpan »

toastercat wrote: post #133
smusamashah wrote: post #131

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 . 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 sear…

You can usually browse npm for what you need, and when you want to use it, look at unpkg.com/ 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…

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, but you can’t download from it.

Re: JSR: The JavaScript Registry

#160

Post by pier25 »

WorldMaker wrote: post #128
pier25 wrote: post #63

Earlier quoted context omitted.

I'm still surprised by so many projects betting on TS. ES will introduce types at some point and all this effort around TS will again divide the JS community.

Technically ES did introduce types already : in the "lost version" ES4. Typescript's syntax was partially inspired from ES4 and while not "compatible" with the previous type system there is more compatibility in the syntax than you might expect. The Type Annotations [0] proposal that TC-39 (in charge of ES standardization) has kept in front of them (at Stage 1 so far) takes the "Python approach" of standardizing the…

I've been complaining about the death of ES4 since it was killed back in 07 or 08.

The proposal might have compat types with TS but what about all the other TS features like generics. Now more than ever, it seems risky to bet the house on TS.

Post reply on HN