In the blog post, I have one example of the React use case with screen capture.
I find it very helpful to have properties defined, so when I use the component, I immediately know what are the props I can provide.
There are some 3rd party React components that won't have type definitions yet, but the popular ones are well covered. I have written most of the components I have used, so I haven't had many problems.
If you use --outDir, wouldn't the .js files that import the transpiled .ts files need to point to outDir instead?
This is the kind of stuff that makes the "incremental" adoption argument hard for me to swallow. If I can't rewrite a .js file to .ts without any further ripple effects within the project, then it's not truly incremental.
I wrestled with this stuff last week and ultimately ended up going with flow since it gave me type checking _and_ incremental adoption, without complicating my existing babel/webpack stack.
Hey, I work on the TypeScript team. I hope you'll reconsider, and maybe you can fill me in on the issues you ran into.
Your .js files should typically be relative to each other, so unless you're using absolute paths (which you usually shouldn't!), this hasn't been a problem for other users. Is there something that I'm missing?
Hey Dan, thanks for responding. I think the key point you may be missing (or perhaps I missed a flag somewhere) is that I want relative requires but I don't want the intermediate js and sourcemap files cluttering up my project (and assuming I have an existing babel/webpack stack I'm happy with -- I just want the type checking).
I want the ability to convert any existing js file within the project to ts without having to touch a single other source file. I also want the type checker to assume that if I don't have a type definition for a package, that I don't want the use of that package to be type checked (without being forced to rewrite my ES6 imports to commonjs).
I was able to do this with flow but not typescript.
Hey rhymohr, I think I see what you mean. If you're already using something like Babel & Webpack, it should just be a matter of using a TypeScript loader like ts-loader[1] or awesome-typescript-loader[2]. TypeScript should just fit into that build step.
Good point! I used similar categorising as Anders Hejlberg used in the JavaScript Jabber podcast (https://devchat.tv/js-jabber/209-jsj-typescript-with-anders-...). For those who don't like audio, he basically referred TypeScript being superset of JavaScript, unlike some other languages.
Often it feels like the CS professors I met at university, who wanted to teach you about "real programming languages and not such toys like JavaScript"
JS is very cool because of how readily available it is and the awesome ecosystem that has grown around it. That said - you don't have to be a CS professor to see that the language (especially in early incarnations) wasn't well designed, to put it nicely. A.H. knows this just like anyone with the skills to design languages and compilers.
Haha, I met him on a JS conf once. There was one of those old "JavaScript has no types and is no real language" guys and he kicked his ass.
Basically he said static typing could be good and there were languages like Scala out there with real good type systems, but most of the "pro static types"-fanboys are using crap like Java or C++.
It also depends on how deep do you want to go with language features.
Let's say you have existing ES2015 source code. You could start experimenting on a local machine and use a script to rename js files to ts. Run the TypeScript compiler and annotate some of the most used functions.
You can then check what is the experience of using those functions that have type annotations, what is the speed of the development, etc.
Sit down with colleagues, show what you have done and ask what do they think. You can then decide to proceed and stick with type annotations until you're sure. Use boy scouts rule: "Always leave the campground cleaner than you found it." aka add typings to the function declaration.
About the text editor: I think all editors use the same TypeScript compiler APIs. That would mean that you would get pretty much same suggestions, error lists, etc. Correct me if I am wrong. VS Code could have some other API calls or project file support.
JS Jabber episode was great! Full of great insights.
I use TypeScript from both Emacs and VSCode, depending on my mood. They do both use the same underlying compiler API, but the VSCode support is more pleasant in how it's surfaced in the editor: ctl-click on a variable to jump to its definition, f2 to rename the variable under the cursor, or ctl-T to open a query field to jump to a symbol.
Emacs is capable of all of these things (because Emacs is capable of anything) but it doesn't work that way out of the box nor is there an already-written package around that makes that easy. To rename you type M-x tide-rename-symbol and it's inconvenient enough that I forget to use it.
It would be interesting to hear more about your experiences. I have been quite hesitant to use more advanced TypeScript features and stayed on a type system related annotations.
