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

171–180 of 183 posts

Re: JSR: The JavaScript Registry

#171

Post by skybrian »

lakpan wrote: post #156
skybrian wrote: post #143

Earlier quoted context omitted.

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.

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.

Re: JSR: The JavaScript Registry

#172

Post by silverwind »

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 legacy, you are supposed to `import` nowadays, like from unpkg.

Re: JSR: The JavaScript Registry

#173

Post by toastercat »

lakpan wrote: post #159
toastercat wrote: post #133

Earlier quoted context omitted.

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.

Unpkg serves whatever is published to NPM, and if it's a library intended for the browser, that often includes minified versions ready for use in script tags, for example, https://unpkg.com/mithril@2.2.2/mithril.min.js. Sometimes the default export is CJS (which has require() calls), in which case, you can usually use the browse url that I mentioned to see if there's another export you can use.

https://esm.sh/ is definitely a good option too if you're OK with modules.

Re: JSR: The JavaScript Registry

#174

Post by toastercat »

joshstrange wrote: post #135
toastercat wrote: post #133

Earlier quoted context omitted.

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…

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

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.

Re: JSR: The JavaScript Registry

#175

Post by lakpan »

toastercat wrote: post #173
lakpan wrote: post #159

Earlier quoted context omitted.

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.

Unpkg serves whatever is published to NPM, and if it's a library intended for the browser, that often includes minified versions ready for use in script tags, for example, https://unpkg.com/mithril@2.2.2/mithril.min.js . Sometimes the default export is CJS (which has require() calls), in which case, you can usually use the browse url that I mentioned to see if there's another export you can use. https://esm.sh/ is de…

Yeah but that's rarely the case, you can't offer that as a generic "solution" to the problem at hand. It's just Mithril's choice to both publish to npm and to officially link to unpkg. Packages can make different choices, like publishing to GitHub releases or just to include the file in the GitHub repo.

The reality is that only frameworks and very popular browser-specific packages do that.

Re: JSR: The JavaScript Registry

#176

Post by toastercat »

lakpan wrote: post #175
toastercat wrote: post #173

Earlier quoted context omitted.

Unpkg serves whatever is published to NPM, and if it's a library intended for the browser, that often includes minified versions ready for use in script tags, for example, https://unpkg.com/mithril@2.2.2/mithril.min.js . Sometimes the default export is CJS (which has require() calls), in which case, you can usually use the browse url that I mentioned to see if there's another export you can use. https://esm.sh/ is de…

Yeah but that's rarely the case, you can't offer that as a generic "solution" to the problem at hand. It's just Mithril's choice to both publish to npm and to officially link to unpkg. Packages can make different choices, like publishing to GitHub releases or just to include the file in the GitHub repo. The reality is that only frameworks and very popular browser-specific packages do that.

I said "often", but you say "rarely", so I guess we'll just have to agree to disagree here. :)

Re: JSR: The JavaScript Registry

#177

Post by lakpan »

skybrian wrote: post #171
lakpan wrote: post #156

Earlier quoted context omitted.

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

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.

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.

Re: JSR: The JavaScript Registry

#178

Post by WorldMaker »

pier25 wrote: post #160
WorldMaker wrote: post #128

Earlier quoted context omitted.

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.

TC-39 isn't "betting the house on TS": the proposal is generic and intentionally doesn't define types it defines syntax for annotations of types. It's basically "type information may appear between a colon after an identifier and an equals sign or other terminator" and "type is a statement keyword with type information following it' and "interface is a block keyword with type information inside that block". That's pretty much the entirety of the proposal: it doesn't state what that type information is (just parsing limits on what it could not be so that it doesn't blow up language parsing), what it is used for (other than that the general idea at runtime is that type annotations are comments just like existing jsdoc comments), or who uses it. While the proposal is trying to stay syntax compatible (again, not types compatible because the proposal doesn't include types) with Typescript it also points out existing overlaps with Closure and Flow type syntaxes and is built so that both of those can use the new syntax for their own, different type systems.

This is why it is a Python-inspired proposal: Python didn't define types, Python defined "here's some places in the language that are effectively ignored like comments that type systems are expected to use". Python has made them more than "just" comments in later proposals and TC-39 holds the right to do that for ES/JS in the future but the current proposal stops about where Python's first proposal did at "types are just fancy inline comments for compilers like (but not limited to) Typescript/Closure/Flow".

Again the proposal itself is a really good read for specifics of where it looks like Typescript and what parts of Typescript are intentionally not supported. For instance as a good reminder there are only three (!) features of Typescript left that aren't ES-standardized and generate code: enums, namespaces, and class parameter properties. Of those, both enums and namespaces have been marked deprecated for a long time and many lint rules exist to help eliminate them from your code if you are still using them.

Re: JSR: The JavaScript Registry

#179

Post by skybrian »

lakpan wrote: post #177
skybrian wrote: post #171

Earlier quoted context omitted.

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.

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.

I meant someone checking out the exact same Github repo (for an application), not someone depending on a library I released. If you have a lock file, it works in that case, I believe?

But actually I use Deno, and I'm honestly not sure how that works either.

As for library dependencies, I know how it works in Go, which is how it should work. When you add a dependency, and it has its own dependencies that you don't use directly, you get the same version that they tested with, which is the lowest one they specified. It only gets overridden if something else requires a higher version.

This means that when a new version gets released somewhere, nothing happens until people notice it, bump a version, and hopefully test it. No library version changes unless there's a commit.

Taking the latest minor version means that it hasn't been tested by anyone downstream. (How could they, when it didn't exist before?)

New library versions should be tested by direct dependencies before they get used by indirect dependencies.

Post reply on HN