12 ms·

Announcing TypeScript 3.9

175 points by munchor 6y ago

shroom 6y ago
Any pro typescripter have any tips for how best use it in existing Node/React codebase? This article mentions material-ui and styled-components. My experience with typescript has been cumbersome with these libraries. A lot of time is spent figuring out what ”types” to return. I find this very difficult in most cases and not fun at all. I figure there must be something wrong in my approach or in my ts config (no explicit any). In short. How to best handle styled-components/material-ui/other library in ts environment? Or is typescript just to much overhead in these usecases?
- TomMarius 6y ago
  Could you post some snippets with which you have difficulties?
- a_humean 6y ago
  I use typescript daily with libraries like those you mentioned. Typescript is not too much overhead, its a huge improvement in the overall developer experience. The main issue I've had with these libraries and typescript is compiler/IDE performance, which 3.9 seems to suggest improvements. I'm not quiet sure what issues you are facing without some examples. Given you are listing react libraries, the react community discord server might be a good place to ask specific questions. They have library and typescript specific channels to ask beginner questions in: https://www.reactiflux.com/ https://www.reactiflux.com/
  - shroom 6y ago
    Thanks for your replies. Glad to hear it's working well for you. I want to learn it myself. Was hesitant to ask questions here because this is not Stackoverflow :-) I will check out the discord. Just to follow up what I meant i created a quick gist. Not working code but maybe can explain it a bit better. What I mean as an example is this. I create a function that uses styled-components. I have no idea what the return type should be at first. I must dig into internals of styled-components and eventually find something like "AnyStyledComponent" which is basically the same as "Any" but for styled-components. https://gist.github.com/slackday/7142251cf2bb3660f8c24492aa1f700d https://gist.github.com/slackday/7142251cf2bb3660f8c24492aa1... This is just one example. Just curious. Not to pick at either Typescript or styled-components which are both great!
    - bryan2 6y ago
      Not sure if there’s an @types package for this. If there’s not I recommend disabling your linter for the line and adding an entry in .d.ts. You lose effectiveness but it still works.
- strogonoff 6y ago
  > How to best handle styled-components/material-ui/other library in ts environment? I’m using Blueprint 3 in TS environment and it’s really nice to get feedback about, say, wrong props passed to one of its styled components right as you type. > My experience with typescript has been cumbersome with these libraries. A lot of time is spent figuring out what ”types” to return. I find this very difficult in most cases and not fun at all. Whether your code is statically typed or not, you generally have to be aware of which data structure goes where—otherwise it’s easy to break things. When code is statically typed, most things break at compile time, enabling your IDE to give immediate feedback. I find the flow much more pleasant if I don’t have to hunt down runtime errors resulting from using a library (BP3 or anything else) in a wrong way. There is some upfront effort in specifying types explicitly where compiler can’t figure it out or does so mistakenly; how fun that is might depend on your personality and established habits. In addition, I believe it heavily depends on tooling—I like using TS in VS Code environment, but TS with Vim (which I’ve been using for many years) was somewhat of a hell. Once in a while I come across an obscure library without TS typings, in which case I would generally provide a `.d.ts` file for it, starting with a catch-all `any` type for its exports, later potentially specifying it further if useful and feasible. This is by far the least fun part.
  - shroom 6y ago
    Oh thanks! Yes my "problem" is mostly around what types to return or rather how to find them. To be aware that separate types package must be installed is definitely something to get into habit. I wasn't aware of the `.d.ts` files. It sounds a lot like what I was looking for! Thanks again for your feedback and help :-)
    - strogonoff 6y ago
      If finding types is especially difficult, it may depend on a particular library (poorly documented types) and on the tooling you use (e.g., VS Code allows to quickly jump to definition/implementation/etc. on any imported class or component in your code, which often takes you to the place in that library where you can find out which types you need and where to import them from; it was a bigger pain in Vim). By the way, keep in mind that it is often unnecessary to specify types explicitly because TS can infer them from context. I used to specify way too many types when I was initially learning TS.
- wdb 6y ago
  Yes, that’s one of my major gripes of Typescript. Once you use something like Emotion you spend a lot of time deciphering the compiler errors. I am told it will be better in the new version. Let’s see if I can find an example
- johnsoft 6y ago
  >A lot of time is spent figuring out what ”types” to return. Typescript infers return types, so even if you don't write out a return type, it will still be fully typed. If you still want to specify the return type, you can take advantage of IDE support. Write the function without an explicit return type, then you can hover over it to see the inferred type, then copy the type. In my preferred IDE (PyCharm), it's even easier since there's a lightbulb action for it. Alt+Enter > "Specify return type explicitly" > Enter
- phamilton 6y ago
  My two cents: Learn to write Typescript, not Javascript. There are Javascript patterns that just don't type well. There are other ways to write your code that will be easier to fit into the type system. It might be more verbose and less reusable at times, but it ends up being a worthwhile tradeoff. That's general advise and might not apply to the libraries you mention, but it's worked well for us to explicitly call out the differences.
- jan_g 6y ago
  Yes, my experience was similar (note, last time I worked with Typescript was about a year ago). It was difficult to use libraries with higher order components or just abstractions in general: redux/thunks, formik, materialui, ... I didn't want to use `any` if at all possible, but instead wanted to have properly defined types. For example, using thunks, one can pass actions directly, or functions that resolve to an action. So, when you're chaining them, it becomes fiddly with types. Compiler complaining about some type or just resolving to any type. I've spent quite some time on that one. Similarly with Formik, I wanted to have generic validators and generic way of applying those validators ... another one that cost me hours to get through and I wasn't satisfied with the result. There is a lot of information around about Typescript, also various guides like the one here: https://github.com/piotrwitek/react-redux-typescript-guide https://github.com/piotrwitek/react-redux-typescript-guide But in the end I've felt that while I've become somewhat proficient with Typescript, I was still quite slow to pump out screens and features. And honestly, I didn't enjoy working with it. (Then there is another can of worms, which is dpendencies and their typings, where it happened that some minor version was bumped and it broke the typings of another library that depended on previous one. So, you might ask, why don't you just pin the dependencies that work together? Well, sometimes an important bug is fixed in a library and you want to upgrade, but you can't, because a person unrelated to library maintainer that handles typings hasn't upgraded them yet ...)
  - eyelidlessness 6y ago
    > It was difficult to use libraries with higher order components or just abstractions in general It's probably a good idea to learn how to use generics (type parameters) effectively. For me, it helped immensely to think of them as basically declarative functions in the type system, with the generic/type parameter being just like a function parameter. The cool thing is that while you have to declare them on a function, a lot of times they can be inferred at the call site. With higher level abstractions, most of the time the types just flow through these generics and you get what you want at the other side just based on inference.
  - acemarke 6y ago
    Note that our new official Redux Toolkit package [0] is written in TS and specifically designed to minimize the amount of types you have to declare in your code, and we have TS-specific guide pages in each of the Redux library docs sites [1] [2] [3], and [0] https://redux-toolkit.js.org https://redux-toolkit.js.org [1] https://redux.js.org/recipes/usage-with-typescript https://redux.js.org/recipes/usage-with-typescript [2] https://react-redux.js.org/using-react-redux/static-typing https://react-redux.js.org/using-react-redux/static-typing [3] https://redux-toolkit.js.org/usage/usage-with-typescript https://redux-toolkit.js.org/usage/usage-with-typescript
- kall 6y ago
  > I figure there must be something wrong in my approach or in my ts config (no explicit any). This is a heretic/unpopular opinion, but I think especially for existing JS/React projects, the laxest possible TS setting is the way to go. You should be able to get to no type errors in your existing JS project with not too many changes. In these contexts (existing projects) I like to think of TS as more editor experience support than seperate language. Modern React is very friendly to TS automatic type inference, so IMHO you should be getting decent benefits from typescript without annotating anything at all. And instead of fixing complicated type errors for no real gain, just // @ts-ignore and move on. I don't know what your specific issue is with styled-components. Should work pretty much out of the box? My suggestion would be to use CSS objects over string literals because that way you get typechecking for your CSS.
  - rkwz 6y ago
    > This is a heretic/unpopular opinion, but I think especially for existing JS/React projects, the laxest possible TS setting is the way to go. Not sure why you think it's "heretic/unpopular", but I think it's the only reasonable way to incrementally migrate an existing codebase to TypeScript.
    - kall 6y ago
      i‘ve read things to the effect of "if you don‘t use noImplicitAny and strictNullChecks you don‘t understand typescript" a bunch but I‘m glad to see the other approach is popular as well.
  - bavell 6y ago
    IMO this is a very pragmatic approach to converting a large project from JS to TS. It's the approach I've been using to gradually convert large existing codebases over to TS without committing to a huge up-front refactor. Definitely agree with you about the IDE experience, just that alone is enough for me to justify the transition.
  - outside1234 6y ago
    I used this approach in a project I migrated to TypeScript as well. My strategy was to start loose, fix those warnings, and then gently turn up the rigor when I had the energy to fix the resultant warnings.
- pimterry 6y ago
  > Any pro typescripter have any tips for how best use it in existing Node/React codebase? https://react-typescript-cheatsheet.netlify.app https://react-typescript-cheatsheet.netlify.app is a super detailed guide to exactly this, complete with worked examples for lots of common cases. Styled Components has a specific section in the docs on using SC with TypeScript, which might be useful too: https://styled-components.com/docs/api#typescript https://styled-components.com/docs/api#typescript
dnpp123 6y ago
I like typescript as it fixes a lot of JS quirks - that's good when you have to write code transpiled to JS. However coming from languages where types are a first element of the language (c++, rust, go...), I often miss a lot of features in typescript (e.g. type conversion overload, generic specialization, etc...) I know that by design Typescript doesn't want those features and I understand the rationale behind it. I'm just wondering if I'm the only one in that case and if someone would know a language transpiling (not compiling) to JS more appropriate to my tastes (and hence with different goals).
- DylanSp 6y ago
  ReasonML, Elm, or Purescript, perhaps? (Not sure what you mean by "transpiling, not compiling")
  - dnpp123 6y ago
    ReasonML looks cool, first time I hear about it. Thanks. Elm/Purescript syntaxes are not my kink. Open to other suggestions though.
    - hocuspocus 6y ago
      Scala.js, Kotlin.js.
    - KitDuncan 6y ago
      ReasonML is the one with the biggest support behind it. It's your best bet.
    - thomasfortes 6y ago
      ReasonML is a pleasure to work with, and if reveryui gets momentum I will surely write gui desktop applications with it (I already use it to write compiled applications, under the hood is just ocaml).
    - metta2uall 6y ago
      Also the Fable & WebSharper compilers for F#
deleted 6y ago
[deleted]
nivethan 6y ago
Mixing commonjs requires and imports is nice.
kuschku 6y ago
Half of the changes are due to the language server implementing refactoring and other similar stuff. This shows clearly why the language server protocol is such a bad design decision and so broken — every language has to implement it itself, and there are no shared features or functionality across languages. Coming from IDEA, where the exact same refactoring functionality and features work no matter if using typescript, kotlin, Rust, C#, golang or dart, exactly identical in all ways, this has been a huge issue for myself. Languages Servers should just expose a clean standardized AST format, representing standardized nodes, and this should in turn allow the IDE to act upon this (which would immediately be represented in changed source).
- tristanstcyr 6y ago
  Language servers could still do this by reusing AST manipulation libraries behind the scenes.
- eknkc 6y ago
  I feel like this is wishful thinking. There is no way you can abstract away so many differences between languages for this to work effectively (or anywhere near as good as a tailor fitted refactoring engine to specific languages) IDEA does a lot of language specific stuff, it just unifies the UX. Which is what language servers aim anyway. BTW, I'm a long term user of powerline-go. Fantastic piece of software!
  - kuschku 6y ago
    > IDEA does a lot of language specific stuff, it just unifies the UX. Which is what language servers aim anyway. Yeah, but with IDEA I have the exact same functionality for Rust, Typescript or Java, while the language servers will never agree on the exact same functions being called the same and doing exactly the same. It means relearning your editor every time you switch your language. I realize I’m probably in the minority as a person who writes basically every project in another language, whichever happens to work best for the project, while most others probably use only a few languages for most of their career, but it’s still annoying.
- 6y ago
ryuukk_ 6y ago
no wasm? they'll miss the revolution, TS could be THE wasm language, knowing Microsoft, they'll be too late..
cryptica 6y ago
IMO, until TypeScript gets the following features, it's not worth using: - Native TypeScript runtime interpreter in Deno (TypeScript alternative to Node.js). - Native TypeScript runtime interpreter in all major browsers. - At least 20% performance improvement over plain JavaScript. The build step has to go away because: - Source maps are unreliable, bulky, slow and add too much complexity for some environments; many environments fail at using them correctly and this can make it difficult to debug code. Being forced to debug ugly transpiled JavaScript is unacceptable and should never happen. - It's slow to work with. TypeScript often claims to be 'scalable' but reality is that large projects often take multiple minutes to build for every change. There are no good incremental build solutions which also do proper type checking. There is no runtime type checking. Native browser support is also essential. The bundling step makes in infeasible to freely mix and match modules written in the two languages in a way which is debuggable. Microsoft should look into Adobe Flash's ActionScript 3 migration from ActionScript 2 for inspiration (both based on ECMAScript spec BTW, just like JavaScript/TypeScript). I remember ActionScript 3 clearly because it was able to deliver a 40% speedup AND runtime type checking... In spite of these huge benefits, I remember that some developers were still hesitant to switch to ActionScript 3! This new generation of developers has clearly lost its ability for critical thinking - I find the current complete lack of resistance to TS is very strange. There are a lot more reasons to resist JS to TS migration compared to AS2 to AS3 migration. I remember in AS2, most people were not declaring types in their code (even though there was support for compile-time type checking). Only in AS3 people started adding Type annotations to their code.
- azangru 6y ago
  > IMO, until TypeScript gets the following features, it's absolutely not worth using That doesn't make sense. Browsers are unlikely to add native typescript support in the foreseeable future; whereas meanwhile typescript offers huge benefits compared to untyped javascript when it comes to large codebases and refactorings.
  - cryptica 6y ago
    >> that doesn't make sense. Browsers are unlikely to add native typescript support in the foreseeable future; It's not my fault that browsers are not going to do it. It doesn't change the fact that it is necessary and that TS is useless without it (the cons outweigh the pros). >> huge benefits compared to untyped javascript when it comes to large codebases and refactorings I've provided you at least 1 robust argument why this is not the case. You've provided 0. I can provide another argument against this: TypeScript only protects the code from compile time type mismatches, it does not prevent every other possible kind of error; it does not even protect the code from runtime type mismatches (for example from JSON objects passed in an HTTP or RPC request). It also does not protect from race conditions, memory leaks, issues with multiple sources of truth, unexpected asynchronous state mutations, poor choice of abstractions, poor encapsulation of state changes, poorly handled runtime exceptions, poorly handled runtime schema validation errors, bidirectional data flow issues (which lead to glitchy state changes and infinite loops), poor choice of ADTs which lead to inefficient code, poor choice of libraries for the use case, misuse of common programming patterns, and any other major logic errors... At best, it projects code from only 5% of all possible bugs; typically the simplest, most obvious kinds of bugs. Please think about this objectively. TS adds value, but very little value and also it takes away value in other ways. For the really difficult runtime bugs which take serious debug time, it adds no value; it makes debugging harder because of its reliance on source mapping. And by the way, instead of down-voting, please try to convince me otherwise because I'm really suffering with the new TS-first reality (I'm on the losing side). I really do want to see the light but I'm not seeing it at all. I'm seeing masses of people running towards a cliff. I know there is a cliff there because I pulled myself out of it (learned the hard way) and have been walking in the opposite direction for the past few years and I don't see why I should go back there simply because that's the direction where all the cool people are heading.
dfabulich 6y ago
Does anybody here know where to go to have conversations with the TypeScript team about adding browser features to better support TypeScript? A lot was happening back in 2018. A Googler put together a proposal to add ignorable "pluggable" type annotations to JavaScript, which would allow browsers to run TypeScript directly without transpilation (and without type checking). https://github.com/samuelgoto/proposal-pluggable-types https://github.com/samuelgoto/proposal-pluggable-types And a member of the TypeScript team at Microsoft put together a proposal to add enums to JS. https://github.com/rbuckton/proposal-enum https://github.com/rbuckton/proposal-enum Neither one of these seem to be active. What happened? What would it be like to get these landed?
- Vinnl 6y ago
  I'm not sure if it's what you mean, but the optional chaining [1] feature added to Javascript (and hence browsers) was championed among others by the TypeScript team. [1] https://github.com/tc39/proposal-optional-chaining https://github.com/tc39/proposal-optional-chaining
- smt88 6y ago
  TypeScript already supports writing type defs as comments in JS files. You get the static checking benefits of TypeScript and can run your code in a browser. It also has enum support. If someone wants to add enums to EcmaScript, it has nothing to do with TypeScript or their team.
  - hoten 6y ago
    yup, via JSDoc.
kbumsik 6y ago
> @ts-expect-error I glad to see this. One of the most painful moment was when writing tests in TS. You will have to deal with countless type errors. Although @ts-expect-error will partially solve the problem, what I have learned is don't write tests in TS - you should test it in the real runtime environment where there is no type checking.
Rapzid 6y ago
The biggest thing killing me right now with TypeScript is more of a general ecosystem issue. That issue being how TypeScript interacts with the concept of "workspaces" and Yarn's Plug'N'Play system. I use TypeScript with ts-node pretty heavily. I'm also trying to use a shared source package outside the root workspace file hierarchy :/

175 points by munchor 6y ago

Any pro typescripter have any tips for how best use it in existing Node/React codebase? This article mentions material-ui and styled-components. My experience with typescript has been cumbersome with these libraries. A lot of time is spent figuring out what ”types” to return. I find this very difficult in most cases and not fun at all. I figure there must be something wrong in my approach or in my ts config (no explicit any). In short. How to best handle styled-components/material-ui/other library in ts environment? Or is typescript just to much overhead in these usecases?

TomMarius 6y ago
Could you post some snippets with which you have difficulties?
a_humean 6y ago
I use typescript daily with libraries like those you mentioned. Typescript is not too much overhead, its a huge improvement in the overall developer experience. The main issue I've had with these libraries and typescript is compiler/IDE performance, which 3.9 seems to suggest improvements. I'm not quiet sure what issues you are facing without some examples. Given you are listing react libraries, the react community discord server might be a good place to ask specific questions. They have library and typescript specific channels to ask beginner questions in: https://www.reactiflux.com/ https://www.reactiflux.com/
- shroom 6y ago
  Thanks for your replies. Glad to hear it's working well for you. I want to learn it myself. Was hesitant to ask questions here because this is not Stackoverflow :-) I will check out the discord. Just to follow up what I meant i created a quick gist. Not working code but maybe can explain it a bit better. What I mean as an example is this. I create a function that uses styled-components. I have no idea what the return type should be at first. I must dig into internals of styled-components and eventually find something like "AnyStyledComponent" which is basically the same as "Any" but for styled-components. https://gist.github.com/slackday/7142251cf2bb3660f8c24492aa1f700d https://gist.github.com/slackday/7142251cf2bb3660f8c24492aa1... This is just one example. Just curious. Not to pick at either Typescript or styled-components which are both great!
  - bryan2 6y ago
    Not sure if there’s an @types package for this. If there’s not I recommend disabling your linter for the line and adding an entry in .d.ts. You lose effectiveness but it still works.
strogonoff 6y ago
> How to best handle styled-components/material-ui/other library in ts environment? I’m using Blueprint 3 in TS environment and it’s really nice to get feedback about, say, wrong props passed to one of its styled components right as you type. > My experience with typescript has been cumbersome with these libraries. A lot of time is spent figuring out what ”types” to return. I find this very difficult in most cases and not fun at all. Whether your code is statically typed or not, you generally have to be aware of which data structure goes where—otherwise it’s easy to break things. When code is statically typed, most things break at compile time, enabling your IDE to give immediate feedback. I find the flow much more pleasant if I don’t have to hunt down runtime errors resulting from using a library (BP3 or anything else) in a wrong way. There is some upfront effort in specifying types explicitly where compiler can’t figure it out or does so mistakenly; how fun that is might depend on your personality and established habits. In addition, I believe it heavily depends on tooling—I like using TS in VS Code environment, but TS with Vim (which I’ve been using for many years) was somewhat of a hell. Once in a while I come across an obscure library without TS typings, in which case I would generally provide a `.d.ts` file for it, starting with a catch-all `any` type for its exports, later potentially specifying it further if useful and feasible. This is by far the least fun part.
- shroom 6y ago
  Oh thanks! Yes my "problem" is mostly around what types to return or rather how to find them. To be aware that separate types package must be installed is definitely something to get into habit. I wasn't aware of the `.d.ts` files. It sounds a lot like what I was looking for! Thanks again for your feedback and help :-)
  - strogonoff 6y ago
    If finding types is especially difficult, it may depend on a particular library (poorly documented types) and on the tooling you use (e.g., VS Code allows to quickly jump to definition/implementation/etc. on any imported class or component in your code, which often takes you to the place in that library where you can find out which types you need and where to import them from; it was a bigger pain in Vim). By the way, keep in mind that it is often unnecessary to specify types explicitly because TS can infer them from context. I used to specify way too many types when I was initially learning TS.
wdb 6y ago
Yes, that’s one of my major gripes of Typescript. Once you use something like Emotion you spend a lot of time deciphering the compiler errors. I am told it will be better in the new version. Let’s see if I can find an example
johnsoft 6y ago
>A lot of time is spent figuring out what ”types” to return. Typescript infers return types, so even if you don't write out a return type, it will still be fully typed. If you still want to specify the return type, you can take advantage of IDE support. Write the function without an explicit return type, then you can hover over it to see the inferred type, then copy the type. In my preferred IDE (PyCharm), it's even easier since there's a lightbulb action for it. Alt+Enter > "Specify return type explicitly" > Enter
phamilton 6y ago
My two cents: Learn to write Typescript, not Javascript. There are Javascript patterns that just don't type well. There are other ways to write your code that will be easier to fit into the type system. It might be more verbose and less reusable at times, but it ends up being a worthwhile tradeoff. That's general advise and might not apply to the libraries you mention, but it's worked well for us to explicitly call out the differences.
jan_g 6y ago
Yes, my experience was similar (note, last time I worked with Typescript was about a year ago). It was difficult to use libraries with higher order components or just abstractions in general: redux/thunks, formik, materialui, ... I didn't want to use `any` if at all possible, but instead wanted to have properly defined types. For example, using thunks, one can pass actions directly, or functions that resolve to an action. So, when you're chaining them, it becomes fiddly with types. Compiler complaining about some type or just resolving to any type. I've spent quite some time on that one. Similarly with Formik, I wanted to have generic validators and generic way of applying those validators ... another one that cost me hours to get through and I wasn't satisfied with the result. There is a lot of information around about Typescript, also various guides like the one here: https://github.com/piotrwitek/react-redux-typescript-guide https://github.com/piotrwitek/react-redux-typescript-guide But in the end I've felt that while I've become somewhat proficient with Typescript, I was still quite slow to pump out screens and features. And honestly, I didn't enjoy working with it. (Then there is another can of worms, which is dpendencies and their typings, where it happened that some minor version was bumped and it broke the typings of another library that depended on previous one. So, you might ask, why don't you just pin the dependencies that work together? Well, sometimes an important bug is fixed in a library and you want to upgrade, but you can't, because a person unrelated to library maintainer that handles typings hasn't upgraded them yet ...)
- eyelidlessness 6y ago
  > It was difficult to use libraries with higher order components or just abstractions in general It's probably a good idea to learn how to use generics (type parameters) effectively. For me, it helped immensely to think of them as basically declarative functions in the type system, with the generic/type parameter being just like a function parameter. The cool thing is that while you have to declare them on a function, a lot of times they can be inferred at the call site. With higher level abstractions, most of the time the types just flow through these generics and you get what you want at the other side just based on inference.
- acemarke 6y ago
  Note that our new official Redux Toolkit package [0] is written in TS and specifically designed to minimize the amount of types you have to declare in your code, and we have TS-specific guide pages in each of the Redux library docs sites [1] [2] [3], and [0] https://redux-toolkit.js.org https://redux-toolkit.js.org [1] https://redux.js.org/recipes/usage-with-typescript https://redux.js.org/recipes/usage-with-typescript [2] https://react-redux.js.org/using-react-redux/static-typing https://react-redux.js.org/using-react-redux/static-typing [3] https://redux-toolkit.js.org/usage/usage-with-typescript https://redux-toolkit.js.org/usage/usage-with-typescript
kall 6y ago
> I figure there must be something wrong in my approach or in my ts config (no explicit any). This is a heretic/unpopular opinion, but I think especially for existing JS/React projects, the laxest possible TS setting is the way to go. You should be able to get to no type errors in your existing JS project with not too many changes. In these contexts (existing projects) I like to think of TS as more editor experience support than seperate language. Modern React is very friendly to TS automatic type inference, so IMHO you should be getting decent benefits from typescript without annotating anything at all. And instead of fixing complicated type errors for no real gain, just // @ts-ignore and move on. I don't know what your specific issue is with styled-components. Should work pretty much out of the box? My suggestion would be to use CSS objects over string literals because that way you get typechecking for your CSS.
- rkwz 6y ago
  > This is a heretic/unpopular opinion, but I think especially for existing JS/React projects, the laxest possible TS setting is the way to go. Not sure why you think it's "heretic/unpopular", but I think it's the only reasonable way to incrementally migrate an existing codebase to TypeScript.
  - kall 6y ago
    i‘ve read things to the effect of "if you don‘t use noImplicitAny and strictNullChecks you don‘t understand typescript" a bunch but I‘m glad to see the other approach is popular as well.
- bavell 6y ago
  IMO this is a very pragmatic approach to converting a large project from JS to TS. It's the approach I've been using to gradually convert large existing codebases over to TS without committing to a huge up-front refactor. Definitely agree with you about the IDE experience, just that alone is enough for me to justify the transition.
- outside1234 6y ago
  I used this approach in a project I migrated to TypeScript as well. My strategy was to start loose, fix those warnings, and then gently turn up the rigor when I had the energy to fix the resultant warnings.
pimterry 6y ago
> Any pro typescripter have any tips for how best use it in existing Node/React codebase? https://react-typescript-cheatsheet.netlify.app https://react-typescript-cheatsheet.netlify.app is a super detailed guide to exactly this, complete with worked examples for lots of common cases. Styled Components has a specific section in the docs on using SC with TypeScript, which might be useful too: https://styled-components.com/docs/api#typescript https://styled-components.com/docs/api#typescript

dnpp123 6y ago

I like typescript as it fixes a lot of JS quirks - that's good when you have to write code transpiled to JS. However coming from languages where types are a first element of the language (c++, rust, go...), I often miss a lot of features in typescript (e.g. type conversion overload, generic specialization, etc...) I know that by design Typescript doesn't want those features and I understand the rationale behind it. I'm just wondering if I'm the only one in that case and if someone would know a language transpiling (not compiling) to JS more appropriate to my tastes (and hence with different goals).

DylanSp 6y ago
ReasonML, Elm, or Purescript, perhaps? (Not sure what you mean by "transpiling, not compiling")
- dnpp123 6y ago
  ReasonML looks cool, first time I hear about it. Thanks. Elm/Purescript syntaxes are not my kink. Open to other suggestions though.
  - hocuspocus 6y ago
    Scala.js, Kotlin.js.
  - KitDuncan 6y ago
    ReasonML is the one with the biggest support behind it. It's your best bet.
  - thomasfortes 6y ago
    ReasonML is a pleasure to work with, and if reveryui gets momentum I will surely write gui desktop applications with it (I already use it to write compiled applications, under the hood is just ocaml).
  - metta2uall 6y ago
    Also the Fable & WebSharper compilers for F#

deleted 6y ago

[deleted]

nivethan 6y ago

Mixing commonjs requires and imports is nice.

kuschku 6y ago

Half of the changes are due to the language server implementing refactoring and other similar stuff. This shows clearly why the language server protocol is such a bad design decision and so broken — every language has to implement it itself, and there are no shared features or functionality across languages. Coming from IDEA, where the exact same refactoring functionality and features work no matter if using typescript, kotlin, Rust, C#, golang or dart, exactly identical in all ways, this has been a huge issue for myself. Languages Servers should just expose a clean standardized AST format, representing standardized nodes, and this should in turn allow the IDE to act upon this (which would immediately be represented in changed source).

tristanstcyr 6y ago
Language servers could still do this by reusing AST manipulation libraries behind the scenes.
eknkc 6y ago
I feel like this is wishful thinking. There is no way you can abstract away so many differences between languages for this to work effectively (or anywhere near as good as a tailor fitted refactoring engine to specific languages) IDEA does a lot of language specific stuff, it just unifies the UX. Which is what language servers aim anyway. BTW, I'm a long term user of powerline-go. Fantastic piece of software!
- kuschku 6y ago
  > IDEA does a lot of language specific stuff, it just unifies the UX. Which is what language servers aim anyway. Yeah, but with IDEA I have the exact same functionality for Rust, Typescript or Java, while the language servers will never agree on the exact same functions being called the same and doing exactly the same. It means relearning your editor every time you switch your language. I realize I’m probably in the minority as a person who writes basically every project in another language, whichever happens to work best for the project, while most others probably use only a few languages for most of their career, but it’s still annoying.
6y ago

ryuukk_ 6y ago

no wasm? they'll miss the revolution, TS could be THE wasm language, knowing Microsoft, they'll be too late..

cryptica 6y ago

IMO, until TypeScript gets the following features, it's not worth using: - Native TypeScript runtime interpreter in Deno (TypeScript alternative to Node.js). - Native TypeScript runtime interpreter in all major browsers. - At least 20% performance improvement over plain JavaScript. The build step has to go away because: - Source maps are unreliable, bulky, slow and add too much complexity for some environments; many environments fail at using them correctly and this can make it difficult to debug code. Being forced to debug ugly transpiled JavaScript is unacceptable and should never happen. - It's slow to work with. TypeScript often claims to be 'scalable' but reality is that large projects often take multiple minutes to build for every change. There are no good incremental build solutions which also do proper type checking. There is no runtime type checking. Native browser support is also essential. The bundling step makes in infeasible to freely mix and match modules written in the two languages in a way which is debuggable. Microsoft should look into Adobe Flash's ActionScript 3 migration from ActionScript 2 for inspiration (both based on ECMAScript spec BTW, just like JavaScript/TypeScript). I remember ActionScript 3 clearly because it was able to deliver a 40% speedup AND runtime type checking... In spite of these huge benefits, I remember that some developers were still hesitant to switch to ActionScript 3! This new generation of developers has clearly lost its ability for critical thinking - I find the current complete lack of resistance to TS is very strange. There are a lot more reasons to resist JS to TS migration compared to AS2 to AS3 migration. I remember in AS2, most people were not declaring types in their code (even though there was support for compile-time type checking). Only in AS3 people started adding Type annotations to their code.

azangru 6y ago
> IMO, until TypeScript gets the following features, it's absolutely not worth using That doesn't make sense. Browsers are unlikely to add native typescript support in the foreseeable future; whereas meanwhile typescript offers huge benefits compared to untyped javascript when it comes to large codebases and refactorings.
- cryptica 6y ago
  >> that doesn't make sense. Browsers are unlikely to add native typescript support in the foreseeable future; It's not my fault that browsers are not going to do it. It doesn't change the fact that it is necessary and that TS is useless without it (the cons outweigh the pros). >> huge benefits compared to untyped javascript when it comes to large codebases and refactorings I've provided you at least 1 robust argument why this is not the case. You've provided 0. I can provide another argument against this: TypeScript only protects the code from compile time type mismatches, it does not prevent every other possible kind of error; it does not even protect the code from runtime type mismatches (for example from JSON objects passed in an HTTP or RPC request). It also does not protect from race conditions, memory leaks, issues with multiple sources of truth, unexpected asynchronous state mutations, poor choice of abstractions, poor encapsulation of state changes, poorly handled runtime exceptions, poorly handled runtime schema validation errors, bidirectional data flow issues (which lead to glitchy state changes and infinite loops), poor choice of ADTs which lead to inefficient code, poor choice of libraries for the use case, misuse of common programming patterns, and any other major logic errors... At best, it projects code from only 5% of all possible bugs; typically the simplest, most obvious kinds of bugs. Please think about this objectively. TS adds value, but very little value and also it takes away value in other ways. For the really difficult runtime bugs which take serious debug time, it adds no value; it makes debugging harder because of its reliance on source mapping. And by the way, instead of down-voting, please try to convince me otherwise because I'm really suffering with the new TS-first reality (I'm on the losing side). I really do want to see the light but I'm not seeing it at all. I'm seeing masses of people running towards a cliff. I know there is a cliff there because I pulled myself out of it (learned the hard way) and have been walking in the opposite direction for the past few years and I don't see why I should go back there simply because that's the direction where all the cool people are heading.

dfabulich 6y ago

Does anybody here know where to go to have conversations with the TypeScript team about adding browser features to better support TypeScript? A lot was happening back in 2018. A Googler put together a proposal to add ignorable "pluggable" type annotations to JavaScript, which would allow browsers to run TypeScript directly without transpilation (and without type checking). https://github.com/samuelgoto/proposal-pluggable-types https://github.com/samuelgoto/proposal-pluggable-types And a member of the TypeScript team at Microsoft put together a proposal to add enums to JS. https://github.com/rbuckton/proposal-enum https://github.com/rbuckton/proposal-enum Neither one of these seem to be active. What happened? What would it be like to get these landed?

Vinnl 6y ago
I'm not sure if it's what you mean, but the optional chaining [1] feature added to Javascript (and hence browsers) was championed among others by the TypeScript team. [1] https://github.com/tc39/proposal-optional-chaining https://github.com/tc39/proposal-optional-chaining
smt88 6y ago
TypeScript already supports writing type defs as comments in JS files. You get the static checking benefits of TypeScript and can run your code in a browser. It also has enum support. If someone wants to add enums to EcmaScript, it has nothing to do with TypeScript or their team.
- hoten 6y ago
  yup, via JSDoc.

kbumsik 6y ago

> @ts-expect-error I glad to see this. One of the most painful moment was when writing tests in TS. You will have to deal with countless type errors. Although @ts-expect-error will partially solve the problem, what I have learned is don't write tests in TS - you should test it in the real runtime environment where there is no type checking.

Rapzid 6y ago

The biggest thing killing me right now with TypeScript is more of a general ecosystem issue. That issue being how TypeScript interacts with the concept of "workspaces" and Yarn's Plug'N'Play system. I use TypeScript with ts-node pretty heavily. I'm also trying to use a shared source package outside the root workspace file hierarchy :/