[diggan]

Yeah, this is what I'm complaining about.

If you're building something that is designed for TypeScript, made for TypeScript and publishes TypeScript sources, then I find it really hard to understand why you'd name it "The JavaScript Registry".

[Vinnl]

Presumably because they don't want to imply that it won't work if you don't use TypeScript.

[seniorsassycat]

I don't think it will, unless you use the npm compatibility layer.

[Vinnl]

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.

[seniorsassycat]

The jsr registry serves typescript, so you have to use typescript tooling, maybe tsc buxy could be esbuild, demo, w/e.

The npm compatibility layer compiles typescript to JavaScript on the registry so you can use it without any typescript tooling.

[Vinnl]

Ah! Looks like it does indeed:

> Unlike with native JSR imports, you are not directly importing TypeScript code. Instead JSR transpiles the TypeScript code to JavaScript before it is installed into your node_modules directory. This generally means that your editor experience will suffer, because “Go to definition” and other features will link to transpiled JavaScript code, or to generated .d.ts files.

https://jsr.io/docs/npm-compatibility#limitations

That said, I'm assuming that if you use Deno, you can write plain JS as well (i.e. the TS library will still work with JS). So yes, you'll need to use the npm compatibility layer if you don't use Deno, but those are the only supported use case.

So I think they still don't want to imply that you have to use TypeScript if you use JSR in the runtimes it's targeting.

[int_19h]

Any valid JavaScript is automatically also valid TypeScript, though.

[billywhizz]

because TS doesn't exist without JS?