3 ms·
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 ap
by 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 agoI'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 agoYou could build it before you check the code in.
- kristiandupont 4y agoI guess, but that seems at least as tedious as maintaining JSDoc comments to me.
- tytho 4y agoYou can still use `tsc` to validate the jsdoc types. It will spit out errors when types don’t match. You can use `tsc` to export the types defined in jsdoc and other projects that import your module will get all the intellisense and type checking as if it had been written in TypeScript.
- ravenstine 4y agoI don't want to use Typescript for everything. A recent example is a Chrome extension I wrote for the sake of proving out a feature. Totally not interested in setting up a build system, dealing with dependencies, type safety, and so forth. I just want to write code and immediately see it run. Having JSDoc is nice to document more than just types, but type hints can be helpful. > 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? You can import types now, at least with VS Code. ``` /* * @typedef {import('./types.js').MyType} MyType */ ``` Haven't found myself using it, though.
- c-hendricks 4y ago> You can import types now When using TypeScript to avoid using TypeScript, yeah. It's not valid JSDoc: https://github.com/jsdoc/jsdoc/issues/1645 https://github.com/jsdoc/jsdoc/issues/1645