5 ms·

As a side note, in editors using js/ts language server from VSCode, you can benefit from these types even in "vanilla" JavaScript with JSDoc. It could look like

by myfonj 4y ago

As a side note, in editors using js/ts language server from VSCode, you can benefit from these types even in "vanilla" JavaScript with JSDoc. It could look like: // @ts-check /// <reference path="./ts-reset-0.3.7/src/entrypoints/recommended.d.ts"/> // = contents of the archive from // https://github.com/total-typescript/ts-reset/releases const allCurrencies = /** @type {const} */(["EUR", "USD"]); /** * @typedef {typeof allCurrencies[number]} currency */ allCurrencies.includes('XXX'); // No 'Argument of type '"XXX"' is not assignable…' error any more. // Would be that error without ts-reset. /** @type {currency} */ let foo = 'EUR'; // OK /** @type {currency} */ let bar = 'XXX'; // that error, expected

FractalHQ 4y ago
I really can’t stand the appeal. It’s so much more verbose and clunky than Typescript. I want to understand why people choose it but I can’t justify using a worse, more verbose, less readable, and less powerful version of Typescript when I can just change a j to a t and have the real deal.
- commotionfever 4y ago
  it doesn't require a build step though
  - latchkey 4y ago
    I love it when my code fails to compile. Machines are good at finding problems. It is a feature, not a bug.
    - myfonj 4y ago
      That's the point. Suggested setup (editor with JS/TS language server constantly checking your code) means you will know about every problem that would possibly break something, you just don't need separate "source code" producing "build package". It means you can ship your code directly to target platform that only understands JavaScript. AFAIK that's not what you currently can do with TypeScript (except Deno).
      - latchkey 4y ago
        All someone has to do is embed one of the fancy new rust tsc implementations into a Node distribution, and be done with it. Deno is not Node.
- myfonj 4y ago
  Not that I've implied it is better or worse or demanded subjective opinions about that, but when we are at it, here are some remarks: 1. No build step is an appealing feature for some. Knowing that what is shipped is what you wrote, not what some transpiler spat out, might have some value. 2. Syntax is also subject of personal preference. Anecdotally, I personally pretty much prefer having "non-executive content" swept aside the "executive" parts, not mixed together in single expression (when applicable). I assume it is matter of habit, but even though I use both TS and JS, to this days, over TS function uppercase (something: string): string { return something.toUpperCase() } I'd really rather prefer seeing the "fluff" (types and comments) separated from the "meat" (actual code): in JS (JSDoc) /** * @param {string} something - glyphs presumably not (only) from upper case * @returns {string} all glyphs from upper case, when applicable */ function uppercase (something) { return something.toUpperCase() } since I still keep mentally stumbling over those :fluffy chunks in TS. Again, probably mater of habit really.
  - schwartzworld 4y ago
    > Knowing that what is shipped is what you wrote, not what some transpiler spat out, might have some value. There aren't that many TS features that actually require transpiling unless you want to write bleeding edge JS, and that's still a factor without typescript. > No build step is an appealing feature for some. ts-node exists My question is how do you reuse and test the JS doc signatures? Can I export comments? Will my tests fail if the types mismatch?
    - kristiandupont 4y ago
      I'm working on a JS project for a client. I can't modify the deployment procedure so I can't add a build step and ts-node is no help because it's frontend. JSDoc comments can be checked with TSC and I get squiggly lines in VSCode. It's a major step in the right direction. Obviously tests work the same they always did, there is no runtime type checking just as there isn't in TS.
      - schwartzworld 4y ago
- tytho 4y ago
  I won’t speak for others, but I for one can’t stand the amount of extra packages needed to get a TypeScript project working. I need to install adapters for my linter, formatter, test runner, editor, bundler to name a few. Hopefully it all works together with all the other plugins and adapters. With the jsdoc version, I just install the `typescript` package, and I can use that to do the typechecking as well export types to be used by a TypeScript project. Sure it’s a bit more verbose, but I’d take that over tinkering with dependencies and configurations.
myfonj 4y ago
For reference, I've suggested such info could be mentioned in the project [0] and author sees as "too niche". [0] https://github.com/total-typescript/ts-reset/issues/93 https://github.com/total-typescript/ts-reset/issues/93

by myfonj 4y ago

FractalHQ 4y ago

I really can’t stand the appeal. It’s so much more verbose and clunky than Typescript. I want to understand why people choose it but I can’t justify using a worse, more verbose, less readable, and less powerful version of Typescript when I can just change a j to a t and have the real deal.

commotionfever 4y ago
it doesn't require a build step though
- latchkey 4y ago
  I love it when my code fails to compile. Machines are good at finding problems. It is a feature, not a bug.
  - myfonj 4y ago
    That's the point. Suggested setup (editor with JS/TS language server constantly checking your code) means you will know about every problem that would possibly break something, you just don't need separate "source code" producing "build package". It means you can ship your code directly to target platform that only understands JavaScript. AFAIK that's not what you currently can do with TypeScript (except Deno).
    - latchkey 4y ago
      All someone has to do is embed one of the fancy new rust tsc implementations into a Node distribution, and be done with it. Deno is not Node.
myfonj 4y ago
Not that I've implied it is better or worse or demanded subjective opinions about that, but when we are at it, here are some remarks: 1. No build step is an appealing feature for some. Knowing that what is shipped is what you wrote, not what some transpiler spat out, might have some value. 2. Syntax is also subject of personal preference. Anecdotally, I personally pretty much prefer having "non-executive content" swept aside the "executive" parts, not mixed together in single expression (when applicable). I assume it is matter of habit, but even though I use both TS and JS, to this days, over TS function uppercase (something: string): string { return something.toUpperCase() } I'd really rather prefer seeing the "fluff" (types and comments) separated from the "meat" (actual code): in JS (JSDoc) /** * @param {string} something - glyphs presumably not (only) from upper case * @returns {string} all glyphs from upper case, when applicable */ function uppercase (something) { return something.toUpperCase() } since I still keep mentally stumbling over those :fluffy chunks in TS. Again, probably mater of habit really.
- schwartzworld 4y ago
  > Knowing that what is shipped is what you wrote, not what some transpiler spat out, might have some value. There aren't that many TS features that actually require transpiling unless you want to write bleeding edge JS, and that's still a factor without typescript. > No build step is an appealing feature for some. ts-node exists My question is how do you reuse and test the JS doc signatures? Can I export comments? Will my tests fail if the types mismatch?
  - kristiandupont 4y ago
    I'm working on a JS project for a client. I can't modify the deployment procedure so I can't add a build step and ts-node is no help because it's frontend. JSDoc comments can be checked with TSC and I get squiggly lines in VSCode. It's a major step in the right direction. Obviously tests work the same they always did, there is no runtime type checking just as there isn't in TS.
    - schwartzworld 4y ago
tytho 4y ago
I won’t speak for others, but I for one can’t stand the amount of extra packages needed to get a TypeScript project working. I need to install adapters for my linter, formatter, test runner, editor, bundler to name a few. Hopefully it all works together with all the other plugins and adapters. With the jsdoc version, I just install the `typescript` package, and I can use that to do the typechecking as well export types to be used by a TypeScript project. Sure it’s a bit more verbose, but I’d take that over tinkering with dependencies and configurations.

myfonj 4y ago

For reference, I've suggested such info could be mentioned in the project [0] and author sees as "too niche". [0] https://github.com/total-typescript/ts-reset/issues/93 https://github.com/total-typescript/ts-reset/issues/93