4 ms·

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

by imbnwa 3y ago

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.

lucacasonato 3y ago
The TypeScript syntax is very stable - there is no spec, but it's very stable. The type system on the other hand: not very stable, and yeah I agree - that would be risky to rely on. However as JSR only relies on the syntax, not on the type system, it's no problem :)
- imbnwa 3y ago
  Is not the 'slow types' problem[0] a type system dependency, or am I missing something? [0]https://jsr.io/docs/about-slow-types https://jsr.io/docs/about-slow-types
  - lucacasonato 3y ago
    It does not use TSC / do type analysis. This is purely syntax analysis. The "slow types" restriction specifically exists because JSR does not use TSC or do type analysis :)
    - imbnwa 3y ago
      Ah, I see
usrusr 3y ago
Consumers don't touch any ts, outside the (technically optional) .d.ts Thecwayvi understand it in theory, the typescript version a library uses could disappear forever the day after a library had been published to JSR and all would be fine. Until someone wants to maintain the code of course, but then you'd have the exact same problem with the elusive typescript version if the repository only took compile output. What JSR would break (or make a deliberately difficult path?) is using some private fork of typescript that isn't even available on the day of publication. The benefit of JSR, as far as I understand it, is offering an easy path to publication that makes type parts not an extra that some might skip but a reliable default. It does make me wonder however, how long-term reliable the finding will be: JSR promises more service than registries before, while also being more tool agnostic. I'm not sure if it's true, but my impression was that in many cases, the registry was primarily bankrolled by however the tooling was funded, e.g. effectively becoming a marketing expense to selling tooling expertise. JSR appears particularly removed from any of that and it's bad enough when the repository fades away in terms of static hosting, it's worse if it also leaves your library without a build process.
pier25 3y ago
I'm still surprised by so many projects betting on TS. ES will introduce types at some point and all this effort around TS will again divide the JS community.
- digging 3y ago
  Is that a good reason to write in raw JS today? I'm not betting anything on TypeScript. It was released 11 years ago, and it's incredibly valuable to me. If it takes another 5 years for ES to implement first-class types, and it's a good implementation, I'll start using ES for new work at that time. What's lost here? TS won't just stop compiling.
  - pier25 3y ago
    I'm not referring to end users like yourself but projects like Deno who have invested a fair amount of resources into supporting TS.
    - digging 3y ago
      Oh, yes, that makes more sense. Still, native typing is not even on the horizon for ES, so I think my point stands for businesses that are heavily invested in supporting TS. TS is what we need today, it doesn't make sense to ignore it because theoretically it could be obsolete in 5-10 years.
- WorldMaker 3y ago
  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 syntax but not the type system still leaving that to external tools (in part because of the lessons from the mistakes of ES4 and the type system that was standardized but never really adopted). The proposal basically assumes that most types will (still) be in the Typescript type system (and would still need Typescript or compatible tool to type check) and maximal (but not complete) compatibility with Typescript syntax is a goal of the proposal. But you don't don't have to take my word on that, the FAQ at the bottom of that Type Annotations proposal is well written and quite detailed. [0] https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations

by imbnwa 3y ago

lucacasonato 3y ago

The TypeScript syntax is very stable - there is no spec, but it's very stable. The type system on the other hand: not very stable, and yeah I agree - that would be risky to rely on. However as JSR only relies on the syntax, not on the type system, it's no problem :)

imbnwa 3y ago
Is not the 'slow types' problem[0] a type system dependency, or am I missing something? [0]https://jsr.io/docs/about-slow-types https://jsr.io/docs/about-slow-types
- lucacasonato 3y ago
  It does not use TSC / do type analysis. This is purely syntax analysis. The "slow types" restriction specifically exists because JSR does not use TSC or do type analysis :)
  - imbnwa 3y ago
    Ah, I see

usrusr 3y ago

Consumers don't touch any ts, outside the (technically optional) .d.ts Thecwayvi understand it in theory, the typescript version a library uses could disappear forever the day after a library had been published to JSR and all would be fine. Until someone wants to maintain the code of course, but then you'd have the exact same problem with the elusive typescript version if the repository only took compile output. What JSR would break (or make a deliberately difficult path?) is using some private fork of typescript that isn't even available on the day of publication. The benefit of JSR, as far as I understand it, is offering an easy path to publication that makes type parts not an extra that some might skip but a reliable default. It does make me wonder however, how long-term reliable the finding will be: JSR promises more service than registries before, while also being more tool agnostic. I'm not sure if it's true, but my impression was that in many cases, the registry was primarily bankrolled by however the tooling was funded, e.g. effectively becoming a marketing expense to selling tooling expertise. JSR appears particularly removed from any of that and it's bad enough when the repository fades away in terms of static hosting, it's worse if it also leaves your library without a build process.

pier25 3y ago

I'm still surprised by so many projects betting on TS. ES will introduce types at some point and all this effort around TS will again divide the JS community.

digging 3y ago
Is that a good reason to write in raw JS today? I'm not betting anything on TypeScript. It was released 11 years ago, and it's incredibly valuable to me. If it takes another 5 years for ES to implement first-class types, and it's a good implementation, I'll start using ES for new work at that time. What's lost here? TS won't just stop compiling.
- pier25 3y ago
  I'm not referring to end users like yourself but projects like Deno who have invested a fair amount of resources into supporting TS.
  - digging 3y ago
    Oh, yes, that makes more sense. Still, native typing is not even on the horizon for ES, so I think my point stands for businesses that are heavily invested in supporting TS. TS is what we need today, it doesn't make sense to ignore it because theoretically it could be obsolete in 5-10 years.
WorldMaker 3y ago
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 syntax but not the type system still leaving that to external tools (in part because of the lessons from the mistakes of ES4 and the type system that was standardized but never really adopted). The proposal basically assumes that most types will (still) be in the Typescript type system (and would still need Typescript or compatible tool to type check) and maximal (but not complete) compatibility with Typescript syntax is a goal of the proposal. But you don't don't have to take my word on that, the FAQ at the bottom of that Type Annotations proposal is well written and quite detailed. [0] https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations