61–70 of 183 posts
Earlier quoted context omitted.
You could also just use `String.prototype.padStart()` [1], and you get a nice optimized C++ implementation :D [1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Pass, not a Rust implementation /s
> You publish TypeScript source, and JSR handles generating API docs, .d.ts files, and transpiling your code for cross-runtime compatibility.
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.
> web-standard ECMAScript modules
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.
> JSR isn't a replacement for the npm registry; it's a superset of npm.
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?
>JSR modules can be used with any JavaScript package manager, and in any project with a node_modules folder.
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...
> Module authors can count on great editor support from strongly typed modules, without the need to transpile and distribute typings manually.
The website seems to insist that distributing typings is a complicated process when it is just the .d.ts files bundled with the published package and an additional entry in the package.json file.
> Easy publishing with a single command - the CLI will walk you through the rest
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.
Man, if only they'd debuted with this, but, hindsight and all. My only thing is that TypeScript has no spec, standard, or competing implementations so it seems a bit risky to treat it as a first-class citizen as far as publishing packages goes.
ES will introduce types at some point and all this effort around TS will again divide the JS community.
As a long-time front-end developer, I'm not seeing a strong value proposition here to justify the further fragmentation another package registry is going to cause. > You publish TypeScript source, and JSR handles generating API docs, .d.ts files, and transpiling your code for cross-runtime compatibility. This sounds like another building service I don't control. There's already too much magic in publishing transpiled…
> Man, if only they'd debuted with this, but, hindsight and all. My only thing is that TypeScript has no spec, standard, or competing implementations so it seems a bit risky to treat it as a first-class citizen as far as publishing packages goes.
Add to that the frequent compilation issues that happen as TypeScript adds or removes types in the global imports, changes language conventions, and updates compilation checks whenever a new version gets released.
Earlier quoted context omitted.
You could also just use `String.prototype.padStart()` [1], and you get a nice optimized C++ implementation :D [1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
While it's not quite C++, here is Chromium's implementation: https://source.chromium.org/chromium/chromium/src/+/main:v8/...
As a long-time front-end developer, I'm not seeing a strong value proposition here to justify the further fragmentation another package registry is going to cause. > You publish TypeScript source, and JSR handles generating API docs, .d.ts files, and transpiling your code for cross-runtime compatibility. This sounds like another building service I don't control. There's already too much magic in publishing transpiled…
Another comment in the thread makes a very good point: > Man, if only they'd debuted with this, but, hindsight and all. My only thing is that TypeScript has no spec, standard, or competing implementations so it seems a bit risky to treat it as a first-class citizen as far as publishing packages goes. Add to that the frequent compilation issues that happen as TypeScript adds or removes types in the global imports, cha…
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?
I think you'd have to write a facade package with a consistent API that mapped to the node/deno/bun equivalents, since they're each quite different. Best bet is to use the Node fs package and rely on the deno/bun compatibility layer. More generally, Deno pushes for Web Platform APIs, and as more are proposed and implemented the runtime-specific APIs will become fewer and fewer.
[0]: https://developer.mozilla.org/en-US/docs/Web/API/Request
[1]: https://developer.mozilla.org/en-US/docs/Web/API/Response
What's the best way to include a binary blob (wasm binary) in your package? For NPM I've been using a bundler (esbuild's `binary` loader) but I'm not sure of the best way to do that in a modern, jsr-friendly way.
We will soon support WASM imports (`import source foo from "./foo.wasm"`). [1] [1]: https://github.com/tc39/proposal-source-phase-imports
As a long-time front-end developer, I'm not seeing a strong value proposition here to justify the further fragmentation another package registry is going to cause. > You publish TypeScript source, and JSR handles generating API docs, .d.ts files, and transpiling your code for cross-runtime compatibility. This sounds like another building service I don't control. There's already too much magic in publishing transpiled…
I mean code itself will be non readable, but in modern build ouput chunks are using regular esm modules, at least for Vite, Rollup, Parcel and so on. Webpack might be different story, but still.
