lucacasonato

It will only replace the secret in headers

We honestly should have just linked to oracle.com instead of evil.com

It’s a cloud service - so you can call out to it from anywhere you want. Just don’t ship your credentials in the app itself, and instead authenticate via a server you control.

We run or own infrastructure for this (and everything else). The link was just an illustrative example

I can confirm Ryan is a real human :)

We'll increase the lifetime in the next weeks - just some tech internally that needs to be adjusted first.

Happy to answer any questions :)

Deno is NPM compatible

JavaScript is the world's most popular programming language.

https://www.statista.com/statistics/793628/worldwide-develop...

You clearly have not read the post :D

It is practically abandoned, but unless the USPTO or a US court says that that is so, it is not legally abandoned. That is a problem because the confusion and insecurity about the trademark remains until it is legally considered abandoned.

That's why we need to file a petition with the US Patent and Trademark office.

like 90% of the DMA is just this haha

Except that is not what Google is doing. They have exclusive access to the one line that is preinstalled for all houses. Only they can use it. And if you want a different provider, you can't use that same line. You have to pay for the installation of a line from that provider with your own cash.

I agree it is very useful! This is also how I discovered this in the first place.

But that is not at all my point. The point is that google.com web properties have access to an API and a browser capability that is not available to it's competitors. Google only allows reading CPU info for itself.

The reason the data is not available for everyone, is because it would be a huge tracking vector. Same reason we don't allow webpages to read the device hostname, or username, or Chrome profile name. Google exposes this to google.com because it trusts itself. That poses this antitrust issue though.

No, this is used by Google Meet right now. Open the "Troubleshooting" panel in meet.google.com in Chrome, and you'll see live system wide CPU usage reporting :)

We do not use GKE.

The Google infra that we do use in this hot path (GFE via Google Global External Load Balancers, and Colossus via Google Cloud Storage) is the same infra that powers serving static assets for Google internal services.

The SLO (objective) is an uptime of 100%. That means that we have no error budget to use for scheduled maintenance or anything of that sort. This means that we can not use software in this hot path that would require scheduled maintenance (ie a relational database that requires periodic downtime for major version upgrades). We additionally minimize risk here: no code that is written by us sits in the path that targets 100% uptime. Ie if it breaks, its due to an upstream failure within Google's web serving infrastructure.

If we were to provide an SLA (an agreement, stating the minimum level of service to a customer) for this service, it would not be 100%. It would be 99.99%. This is to avoid risk. But we can still have a higher internal target than the provided SLA.

If we have to make all changes in a way that requires that we do not even have 8 seconds of downtime a year (but 0 seconds of downtime), that significantly changes how you design a system and roll out changes.

TLDR: SLA != SLO

It uses Google Cloud Tasks

Hey hey, post author here - happy to answer your questions!

So the reason we do this - and I should have mentioned this in the post - is that we explicitly do not want to dog food here. Because JSR is the package registry, if it goes down, and we can not pull packages from the registry during deployment of a new version of the registry (that fixes the reason it is down), that would be very bad. So we don't put anything that depends on the registry in the path of deployment of the registry :)

Also, a lot of the work that the registry does (parsing source code, analyzing dependencies, enforcing rules on the code, etc) are pieces of code that are shared with the Deno CLI, which implements this in Rust. The reason for this is that this work has to happen in Rust, because JavaScript, for the most part, can not "self-host" itself (ie you can not implement a JavaScript runtime on a JavaScript host if you want your runtime to provide more system bindings than the host runtime).

Finally, we do use Deno for many pieces of the registry where the "circular dependency" problem is not relevant. Namely the entire frontend uses Deno and Fresh :)

CORRECTION:

An employee of GitHub has reached out to me to inform me that there are more than 2 engineers people working on npm full time, including multiple full time support staff and full time staff to review possible malware. The engineering team working on npm is "substantially larger than 2". Additionally they informed me that a new product manager for npm will be starting tomorrow.

Even though I made no claim to the contrary, I would like to emphasise that there are obviously current product managers at GitHub that product manage npm as _one of_ the projects they manage.

Doesn't this get us right back to where we started from? Where you don't want users to be able to register arbitrary names :)

Both `.d.ts` and `.js` files can be created without understanding the TS type system (this is what JSR does). Creating both of those is just a TS syntax transform - one that is highly stable (esbuild and friends all do it already).

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

PRs welcome: https://github.com/jsr-io/jsr

How do you deal with individuals that may not have a domain? What do you tie their scope to?

> 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

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

For tools that natively support TypeScript, you can directly consume the TypeScript source code. No transpilation necessary. The complexities are only introduced (well not really introduced, just moved somewhere else) for tools that do not natively support JS.

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

That doesn't matter. If everyone settles on one standard, even if you do post process, tools become simpler. The idea is not that you must ship your code unbundled to the browser. It is to reduce the amount of complexity incurred in the process from source -> dist. I am sure you agree that the lower the difference between source and dist, the easier debugging and developement in general are :)

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

They do work in npm. In npm packages you can depend on JSR packages, and on JSR you can depend on npm packages.

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

Nope! JSR is not a package manager. JSR is only a runtime. When you install into a node_modules folder, the layout in this folder is the same between JSR and npm packages. So any downstream tool does not even need to know JSR is in the loop - it just works. This is one of the key points to ensure easy adoption of JSR by anyone.

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

I understand this.

The problem is the following: npm is owned by GitHub/Microsoft, and GitHub/Microsoft does not care about npm. To GitHub, npm is a cost center. npm has no dedicated product manager at GitHub. Last I heard, npm has _two_ dedicated engineers working on it. The last real new feature npm shipped was package provenance (last year). It took npm 5 years to ship the file browser (because GitHub/Microsoft did not care about npm, and thus effectively froze all feature dev work on npm).

If we want innovation in the space, we need to do it in a way that a) keeps backwards compat with npm (which JSR does, both ways), but b) we need to move away from npm in the long term. JSR is an attempt at this (while trying to stay within the constraints posed).

Look at the comment under the comment you mention - those issues are about the TS type system, NOT the TS syntax. TS syntax is highly stable, and is the only thing JSR relies on :)

What happens if the domain registration expires? Scope takeover?