My recommendation would be to not let it slow you down. Make good use of the typescript config file, ensuring that the strictness is calibrated to the level you need. It's phenomenally productive to catch sneaky bugs at compile time, even if it may not seem that way on the front leg of dev.
The awesome thing about the ts-config compiler options is that you can scale them up over time. The goal is to have full strictness enforced, but if and when that slows you down then by all means dial it back. The goal is DX and developer productivity, it just so happens that specifying types at compile time do allow for huge amounts of preventative measures
I am passionate about creation, be it code or written. I believe that knowledge should be sharee. If we all gave a little bit of our time to helping the each other, the world would be a better place.
I'm not particularly fond of TypeScript - overall I view it as having poor ROI but decided to learn it anyway so that I could at least have a somewhat coherent base to criticize it from.
That said I accidentally fell into an interesting work flow. I was trying to use uvu with TypeScript. It uses tsm to test TypeScript code.
With that setup you can actually focus entirely on getting your unit tests done first without paying any attention to TypeScript - type checking (linting) only occasionally when the test results don't make any sense (i.e. overall the tests where more effective pointing out issues than TypeScript).
Once you're done with a unit of work you can then focus on what TypeScript is complaining about - "oh yeah, I better clean that up".
That allows a "JavaScript style" work flow with (a sprinkling of) explicit TypeScript types for documentation.
Basically use fast non-checking transpilation with a fast loader for reqular work and only run the full type check at the end or when things get weird.
I am passionate about creation, be it code or written. I believe that knowledge should be sharee. If we all gave a little bit of our time to helping the each other, the world would be a better place.
Not sure what you are hoping to find but recently I put together solid-hackernews-a.
Vite uses esbuild for "discarding type annotations" - so npm run dev doesn't type check (presumably that is supposed to happen a priori in the IDE/language server enabled editor). npm run lint:types is used separately for static type checking.
I am passionate about creation, be it code or written. I believe that knowledge should be sharee. If we all gave a little bit of our time to helping the each other, the world would be a better place.
My recommendation would be to not let it slow you down. Make good use of the typescript config file, ensuring that the strictness is calibrated to the level you need. It's phenomenally productive to catch sneaky bugs at compile time, even if it may not seem that way on the front leg of dev.
The awesome thing about the ts-config compiler options is that you can scale them up over time. The goal is to have full strictness enforced, but if and when that slows you down then by all means dial it back. The goal is DX and developer productivity, it just so happens that specifying types at compile time do allow for huge amounts of preventative measures
See, no one ever mentioned this to me - that I can choose how I want to work.
I will look into making it work for me and not the other way around.
This makes more sense
I'm not particularly fond of TypeScript - overall I view it as having poor ROI but decided to learn it anyway so that I could at least have a somewhat coherent base to criticize it from.
That said I accidentally fell into an interesting work flow. I was trying to use uvu with TypeScript. It uses tsm to test TypeScript code.
With that setup you can actually focus entirely on getting your unit tests done first without paying any attention to TypeScript - type checking (linting) only occasionally when the test results don't make any sense (i.e. overall the tests where more effective pointing out issues than TypeScript).
Once you're done with a unit of work you can then focus on what TypeScript is complaining about - "oh yeah, I better clean that up".
That allows a "JavaScript style" work flow with (a sprinkling of) explicit TypeScript types for documentation.
Basically use fast non-checking transpilation with a fast loader for reqular work and only run the full type check at the end or when things get weird.
This is realty interesting... Is there a public repo I can look at?
Not sure what you are hoping to find but recently I put together solid-hackernews-a.
Vite uses esbuild for "discarding type annotations" - so
npm run dev
doesn't type check (presumably that is supposed to happen a priori in the IDE/language server enabled editor).npm run lint:types
is used separately for static type checking.Not looking to find anything specific. I understand technologies better by having a look at how people use them over reading the docs...
I'll have a look, thank you