TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

JSR Is Not Another Package Manager

75 点作者 sbt567大约 1 年前

12 条评论

lrvick大约 1 年前
&quot;To publish provenance for a package, you must publish the package from a GitHub Actions workflow.&quot;<p>Read as: &quot;We wish to uphold NPM tradition of not allowing the authors of code to sign their own code, but as an alternative we will increase your package trust score if you build your package with a heavily censored, centralized, and proprietary build system owned by Microsoft&quot;<p>How is it that STILL the only source for signed javascript packages are Debian apt-get repos. NPM and JSR still have dramatically worse JS supply chain security than a -terrible- 30yo package manager which still requires a lot of custom tooling overhead in every project for reproducible builds (docker, apt package hash pinning, apt-archive, etc).<p>Oh right, because the NPM team was worried even having -optional- support for package signing would scare off people from publishing javascript packages.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;npm&#x2F;npm&#x2F;pull&#x2F;4016">https:&#x2F;&#x2F;github.com&#x2F;npm&#x2F;npm&#x2F;pull&#x2F;4016</a>
Philip-J-Fry大约 1 年前
I think true innovation here would be forgoing a centralised package registry and just using good old file systems. Go modules have the the right idea, pull a package from a server which responds to basic HTTP requests or even a file system. If you want some smart searching capability, or generated docs then create a proxy which packages are downloaded through which allows you to index them.<p>Just take things back to basics. You shouldn&#x27;t have to publish a package on some centralised registry, you should just be able to import a package from anywhere.
评论 #40156837 未加载
评论 #40155538 未加载
评论 #40156081 未加载
评论 #40155767 未加载
评论 #40157161 未加载
评论 #40155415 未加载
评论 #40156264 未加载
mike_hearn大约 1 年前
What&#x27;s the business model, I wonder? The reason npm registry didn&#x27;t evolve much is that it is expensive to give away cloud services and eventually got sold to Microsoft, who presumably assessed that adding features wouldn&#x27;t drive much extra revenue. How many people publish private packages to npmjs.com how much does it cost to host and serve the ever growing collection, especially as they&#x27;re pretty lenient about people serving large binaries from it?<p>The Java world got burned by this a few years ago when JFrog shut down Bintray, which had been the second largest open source package repository after Maven Central. A ton of stuff had to be republished, a ton of build configs updated. Now Maven Central is hopefully Too Big To Fail and Sonatype is a sustainable independent business, partly due to the widespread practice of companies buying its Nexus product to mirror Central internally, something I haven&#x27;t seen so much of in the JS space, and partly because the Java ecosystem doesn&#x27;t tend to host giant binaries off it. But still.<p>Gotta admit, I&#x27;d like to see a more decentralized approach become popular here. There&#x27;s no specific reason packages always have to be hosted in one or two central registries.
评论 #40155135 未加载
评论 #40155802 未加载
评论 #40155109 未加载
评论 #40155291 未加载
评论 #40155420 未加载
评论 #40154899 未加载
chrisldgk大约 1 年前
Though I‘m not sure if it will get adopted by as many people as NodeJS (and other kind-of drop-in replacements like Bun) did, I‘m really excited by the innovation that Deno brings to the JS&#x2F;TS space. Particularly actually looking at the hassles that working with NodeJS currently brings and trying to find elegant solutions to that is an admirable goal. If Deno doesn‘t get adopted by many people, maybe at least some of these ideas can later find their way into other runtimes.<p>As anyone that has tried to publish hybrid packages that include types, a CJS and an ESM version, all the while maintaining semver and anything else can be a real hassle. Everyone seems to have a different solution, and most of the time you end up writing a convoluted build system for your package consisting of an amalgamation of tsc, esbuild, rollup or whatever other bundler is the hot new stuff.
pjmlp大约 1 年前
Based on similar experience from other language ecosystems since Perl introduced CPAN, unless a customer requires me to use JSR, I am not rely convinced to stay away from npm repos.
eqvinox大约 1 年前
Sure, it&#x27;s not a &quot;Package Manager&quot; by JavaScript nomenclature, where apparently the package manager refers only to the client side piece. Instead it&#x27;s apparently a &quot;Package Manager&quot; and a &quot;Package Registry&quot;… which most other environments just call a &quot;package manager&quot;.<p>As a non-JavaScript developer, drawing this distinction feels incredibly silly to me…
评论 #40157241 未加载
评论 #40156526 未加载
评论 #40155434 未加载
评论 #40156852 未加载
thenerdhead大约 1 年前
I like how they encourage best practices using a score similar to pub.dev &amp; what npm tried to do years ago. Also the compatibility portion is quite interesting given the evolution of runtimes.<p>I suppose I don&#x27;t quite understand the rationale of another registry. But perhaps that is what is needed nowadays with various ecosystems and their chosen defaults. What for example prevents npm from adopting ES modules tomorrow? (Although there are many opinions on CommonJS&#x2F;ES Modules)
posix_monad大约 1 年前
TypeScript is not a good foundation to be building on. The language has very complex semantics and the only &quot;spec&quot; is the main implementation, which is also evolving.
评论 #40155492 未加载
评论 #40155456 未加载
dinckelman大约 1 年前
My motivation to host in this repository completely vanished, the moment I realized that any Zod types are considered slow, and will not produce any type definition on JSR as a result.<p>On a surface level, they have automatic mechanisms for everything that my projects already have implemented, except it has arbitrary limitations, and not a whole lot of material explaining them properly
nailer大约 1 年前
&gt; higher scores are awarded to packages that include comprehensive JSDoc documentation on each exported symbol<p>Nope. I love Ryan Dahl, but code filled with JSdoc comments that needlessly replicate type information already in the code, and mandatory descriptions for every variable (often used as a substitute for proper naming) has a really low signal:noise ratio.
hamilyon2大约 1 年前
Well of course. JSR is java specification request.
thriftwy大约 1 年前
I thought that JSR is an RFC for Java - can we please be more creative than reusing TLAs?<p>Call it Genet.
评论 #40155081 未加载