TypeScript 2.4 RC(blogs.msdn.microsoft.com)
blogs.msdn.microsoft.com
TypeScript 2.4 RC
https://blogs.msdn.microsoft.com/typescript/2017/06/12/announcing-typescript-2-4-rc/
27 comments
Of course, it looks like all of the breaking changes introduce compile time errors, so if you try it out and it compiles, you're good!
That's an incredibly smooth transition. Microsoft has really learned from the javaverse's mistakes regarding compatibility.
We've been using string enums for about a year now using this:
enum StringEnums {
aStringEnum = <any> "aStringEnum"
}
The await import to lazy load modules is quite impressive. TypeScript goes more and more beyond the compile-to-js promise
Dynamic imports is standards-track JS :) http://2ality.com/2017/01/import-operator.html
It might be better to have runtime system load code dynamically when necessary, without programmer to care about this, e.g. on first invocation, maybe pre-loading it based on call statistics from previous app runs. People implement this already (I tried this too - https://github.com/avodonosov/pocl)
I wonder how to get it all working with webpack? Does it use require.ensure?
Webpack 2 supports import()
Yup - one of the maintainers of ts-loader here. I haven't had chance to test it yet but I'm pretty confident this should just work with ts-loader (and awesome-typescript-loader as well I should think)
Hey, can I ask you a quick question (and I understand if you can't respond). I'm using React + TypeScript for some server-side stuff, but because I'm using style-loader/css-loader, I have to use webpack.
Everything works, including sourcemaps, but when I debug using VSCode, setting a breakpoint puts me in a 'read-only' version of the file. It's not a lot of 'work' to switch to the actual file, but long-term it's hella inconvenient.
Is there a way to get VSCode (or another editor) to drop me into the actual file, or is this just a consequence of using webpack?
Everything works, including sourcemaps, but when I debug using VSCode, setting a breakpoint puts me in a 'read-only' version of the file. It's not a lot of 'work' to switch to the actual file, but long-term it's hella inconvenient.
Is there a way to get VSCode (or another editor) to drop me into the actual file, or is this just a consequence of using webpack?
I was wondering what the string enum example compiled into. Its this.
https://gist.github.com/scttcper/7691497d4b8db9ad6e599aa2d34...
https://gist.github.com/scttcper/7691497d4b8db9ad6e599aa2d34...
Seems reasonable
They've finally begun backtracking on function parameter bivariance. https://blogs.msdn.microsoft.com/typescript/2017/06/12/annou...
They still think they're right: "Our experience has been that users generally don't run into issues with this all that much", but they've started to "tighten[] things up and compare[] the parameters which are callbacks specifically". I'm just so excited and annoyed that they've finally partially admitted they're wrong. Double annoyed that we're still on TS 1.8 :(
I just don't understand function parameter bivariance. It's not just that it's wrong (if it was just theoretical I wouldn't've noticed), it's that it keeps letting bugs through. You simply can't refactor the code and then fix it till there's no errors because you'll run out of errors before you run out of things that need changing. Or adding features in React+Redux, can you get it to help you? Nup. At least that's a specific point you can remember to check.
They still think they're right: "Our experience has been that users generally don't run into issues with this all that much", but they've started to "tighten[] things up and compare[] the parameters which are callbacks specifically". I'm just so excited and annoyed that they've finally partially admitted they're wrong. Double annoyed that we're still on TS 1.8 :(
I just don't understand function parameter bivariance. It's not just that it's wrong (if it was just theoretical I wouldn't've noticed), it's that it keeps letting bugs through. You simply can't refactor the code and then fix it till there's no errors because you'll run out of errors before you run out of things that need changing. Or adding features in React+Redux, can you get it to help you? Nup. At least that's a specific point you can remember to check.
Typescript has pretty good support for react and redux.
Looking forward to the string enums! I've been using https://github.com/Microsoft/TypeScript/issues/3192#issuecom... but it'll be nice to have this built-in.
The term "weak types" is incredibly confusing to developers who have used languages that support weak references. I was excited for a second there thinking that "weak types" meant TypeScript would generate code for using a `WeakMap` in order to create weak references, but I guess not.
[deleted]
Very excited for type safe dynamic imports. Should make type safe code splitting with webpack a breeze.
Can someone compare Flow and TS? Last time I worked with Flow I had to constantly restart the server to get fresh typechecks. Is that still the case? Other pros and cons?
https://djcordhose.github.io/flow-vs-typescript/elm-flow-typ... compares Flow TS and Elm :)
That was great, thanks.
Here are some more technically inclined comments (on why typescript is terrible compared to flow :)
https://news.ycombinator.com/item?id=14472810
Graph vs AST approach, although I cannot speak for its veracity.
http://thejameskyle.com/adopting-flow-and-typescript.html
Fwiw, this page blocks when you come from HN. I suspect the author wouldn't want their stuff posted here.
I've found the Flow server seems to be much more stable these past few months.
All in all looks like a solid release, although breaking changes means I'll be a little hesitant with updating anything critical :)