ts-node still only has experimental support for ESM. ts-mocha doesn't work well at all, and watch-mode is unusable with the experimental esm-loader. TS for a long time was not on par with NodeJS package entrypoints feature. TS all around has given me massive headaches. This is amplified for every tool (tests, demos, linters) I've tried to add to my project due to requiring TS loaders/parsers, even in Node packages that are not targeting browser environment. If TS works for you because your stack comes with all batteries included and TS-compatibility is guaranteed, more power to you, but not everyone is using your stack.
ts-node is slow, I would use ts-node-dev for watch mode. I've not had any problems with it except when developing CLI tools. Sorry TS has given you headaches, but it sounds to me like you're trying to make it more complicated than it really is... Not sure what kind of stack you're running, but every test tool i've used had support for typescript (jest, mocha, cypress) and eslint as well... don't use tslint and follow the official documentation from the tools you're using. A lot of the tutorials online are needlessly complicated and very very out-dated.
CLI tools is among the things I create. Either way, I'm not the one making it complicated, TS compile-step is making it complicated, JSDocs is making it uncomplicated. Admittedly, ESLint was pretty easy, but I use a different test-runner and my fight was also with Storybook, but it has been a while, maybe it has improved. Anyway, it doesn't matter, my point is that you cannot deny that if you move from JS to TS files, you will need to make all of your devtools, whether that's testing, linting, demoing, whatever, compatible with your compilation-step. We can argue about how much effort it really is, or should be, the point is that it's always less effort if you don't need to introduce the compilation-step. You might not like the JSDocs comment syntax, you may not like writing some types in separate hand-written .ts or .d.ts files to import into your JSDocs comments, but the dev setup overhead is certainly a lot less, and moving to a new tool is a lot simpler as you don't need to think about the compilation-step.
Were those headaches saved by TS compile step or by the type safety TS gives you? Because the latter, you still have it with JSDocs/JS files, it's the same tool (TS) analyzing your code, building the type definitions and having your editor scream at you when you mess something up.
Thing is, 98% of the code I write is being transpiled anyway, so it's actually more of a hassle to not use TS in this environment.
When I do write code that doesn't absolutely have to be transpiled, I may definitely explore this JSDoc stuff. Transpiling stuff isn't giving me very much trouble at the moment, though.
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
ts-node still only has experimental support for ESM. ts-mocha doesn't work well at all, and watch-mode is unusable with the experimental esm-loader. TS for a long time was not on par with NodeJS package entrypoints feature. TS all around has given me massive headaches. This is amplified for every tool (tests, demos, linters) I've tried to add to my project due to requiring TS loaders/parsers, even in Node packages that are not targeting browser environment. If TS works for you because your stack comes with all batteries included and TS-compatibility is guaranteed, more power to you, but not everyone is using your stack.
ts-node is slow, I would use ts-node-dev for watch mode. I've not had any problems with it except when developing CLI tools. Sorry TS has given you headaches, but it sounds to me like you're trying to make it more complicated than it really is... Not sure what kind of stack you're running, but every test tool i've used had support for typescript (jest, mocha, cypress) and eslint as well... don't use tslint and follow the official documentation from the tools you're using. A lot of the tutorials online are needlessly complicated and very very out-dated.
CLI tools is among the things I create. Either way, I'm not the one making it complicated, TS compile-step is making it complicated, JSDocs is making it uncomplicated. Admittedly, ESLint was pretty easy, but I use a different test-runner and my fight was also with Storybook, but it has been a while, maybe it has improved. Anyway, it doesn't matter, my point is that you cannot deny that if you move from JS to TS files, you will need to make all of your devtools, whether that's testing, linting, demoing, whatever, compatible with your compilation-step. We can argue about how much effort it really is, or should be, the point is that it's always less effort if you don't need to introduce the compilation-step. You might not like the JSDocs comment syntax, you may not like writing some types in separate hand-written .ts or .d.ts files to import into your JSDocs comments, but the dev setup overhead is certainly a lot less, and moving to a new tool is a lot simpler as you don't need to think about the compilation-step.
TS has given me headaches, too. What's not quite as easily quantifiable is how many headaches TS has saved me from
Were those headaches saved by TS compile step or by the type safety TS gives you? Because the latter, you still have it with JSDocs/JS files, it's the same tool (TS) analyzing your code, building the type definitions and having your editor scream at you when you mess something up.
They were definitely solved by the typesafety
Thing is, 98% of the code I write is being transpiled anyway, so it's actually more of a hassle to not use TS in this environment.
When I do write code that doesn't absolutely have to be transpiled, I may definitely explore this JSDoc stuff. Transpiling stuff isn't giving me very much trouble at the moment, though.