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)
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?
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?
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.
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.
27 comments
[ 3.2 ms ] story [ 54.6 ms ] threadAll in all looks like a solid release, although breaking changes means I'll be a little hesitant with updating anything critical :)
https://gist.github.com/scttcper/7691497d4b8db9ad6e599aa2d34...
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?
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.