Show HN: Boilerplate for Node.js and TypeScript with Jest tests
github.com
github.com
1. You can generate source maps for your TS files, but node can't use them. There is some support for source maps via the node-source-map-support, but it doesn't play well with a lot of stuff out of the box. Just getting accurate stack traces in my logs turned into a project of its own.
2. Most node libraries don't include type definitions, and what is on DefinitelyTyped is more likely than not to be out-of-date and inaccurate. Having the wrong type definitions might be worse than none at all, which means for the most part you'll be declaring a lot of stuff as "any." It makes even preserving the types in your own code difficult, as anything that touches a 3rd-party library is going to come back as the any type without additional annotation.
3. Similar to 2, if you want to use a promise-based approach to deal with the "callback hell" induced by node's continuation passing style, you are probably going to need to use a library that does runtime mutation of the many libraries that don't support promises, which means that any time information you do have about 3rd-party libraries is going to get lost.
4. The last two items, combined with the lack of runtime type checking, means that your types are going to be difficult to maintain and can easily become inaccurate without feedback from the compiler to let you know that something is wrong.
Source maps in node are working fine for me in intellij. I can set breakpoints in the typescript code and step from there with full inspection capabilities.
The library compat issues you're describing I didn't have. I used what MS recommends or uses itself in the bot framework, which is of course all nicely compatible (e.g. mocha/chai/sinon for unit tests). For promises I used regular ES6 promises, so that wasn't an issue either.
Also regarding ES6 Promises. The issue I'm referring to has to do with using 3rd-party libraries that don't provide promise support, which is a lot of popular node libraries. Even if you have type definitions for them, if you use a library to auto-wrap the API to provide promises (which is, as far as I know, still the only way to do it without writing your own Promise wrappers, you lose not only your completions, but also information about the returning types, and the compiler will complain.
I believe most of these problems will resolve in time. I'm sure node will add built-in support for source maps some day, and most libraries will eventually come with Promise APIs.
The problem that will be much more difficult to address is the lack of reliable type information for most libraries. That of course isn't really Typescript's fault, as it just has to do with the fact that most library devs in the node community are writing in JS, but it also strikes me as something that will limit adoption of TS amongst backend developers looking for a static type system.
I did indeed wrap the callbacks into promises myself, so haven't looked into promises libraries, but I can't imagine there isn't an officially sanctioned solution for this.
Re 2: I do agree that this is a problem but remember that it's all just a community effort. You can always create your own type definitions or enhance existing ones and share on the DefinitelyTyped repository. Also, most of the time if a type definition is out of date or invalid, you can just create your own partial typedef for a module with only those several methods you are actually using.
Re 3: IMO it's a feature. By using, for e.g. a bluebird library to wrap third party code in a Promise, you are changing the way how your code is interacting with that library by redeclaring the whole library or some parts of it. TSC is complaining because you've changed the declarations. You have to provide your own type definitions, either inline, or for the whole module.
I've engineered or reviewed several projects that are using TypeScript with success. The teams after initial hiccups are mostly not willing to come back to pure JavaScript now.
I'm not advocating to use TS everywhere and for every project. It all depends. Many factors must be considered but some sort of type checking is usually a good thing to have.
Per your follow-up comments:
1. Have you gotten node-source-map-support to work with a logging framework like Winston that handles uncaught exceptions? It didn't work out of the box for me, but I'm sure that with some effort it could be made to work.
2. Yea. I think a big part of the problem is that even a lot of very popular node libraries just aren't that stable. APIs change a lot and the documentation is poor, so keeping a type definition up-to-date and accurate is particularly difficult.
3. I agree that that is by design, but that doesn't make it any less of a barrier to using promises across an application that depends on a lot of 3rd party libraries, and as a developer I don't want to have to spend a lot of my time maintaining type definitions to work around it in my project.
I agree that having used Typescript I would not want to move back to plain JS, but for me the experience pushed me away from using node as a backend in the future, as I think there are other platforms that provide the same benefits without the drawbacks and difficulties.
In the end, my solution has been to just use only the DefinitelyTyped typings that work well, and fall back to inserting my own broad, liberal `declare`s for remaining libraries. This has the enormous drawback of effectively opting out of most of the benefits of using TypeScript in the context of those specific libraries, but it seems like a worthwhile trade-off given I keep the benefits throughout a lot of the app.
I haven't encountered #1 personally - this seems to work OK in my experience.
On #3, I've always thought both that "callback hell" was exaggerated and largely called by badly planned code rather than being a fundamental problem with callbacks, and also that Promises are an oversold solution that offer some benefits but are certainly no magic bullet. My code generally uses Promises, but never pervasively. They wouldn't be a dealbreaker by any means.
TL;DR while your criticisms are understandable and valid, they seem relatively minor based on my own experience. Abandoning an app completely seems extreme.
- Typescript has excellent dev tooling. I've been using vs code and intellij, and typescript integration is first class.
- Typescript seemed to have a richer type system. I didn't look deeply enough into flow to know for sure though.
- Outside of facebook flow didn't seem to have much traction. With angular 2 being built with typescript I have more confidence in it sticking around.
Usually I tend to lean towards TypeScript due to:
- Much better tooling and editor/IDE integration (I'm using vscode and WebStorm),
- DefinitelyTyped repository and the availability of type definitions,
- It's subjective but TS has better documentation and examples,
Don't get me wrong, the Flow (and React) community is doing a great job and in my opinion Flow is a very good tool for static type checking. The real problem with both is the coverage/quality of type definitions and the amount of time it takes to create typedefs. Right now there are many more typedefs available for TypeScript and the community is stronger and more active.
Also, right now one common format or conversion between definition formats is not possible, see: https://twitter.com/lbljeffmo/status/787692583350829056
Writing unit tests in TypeScript can sometimes be troublesome and confusing. Especially when mocking dependencies and using spies."
Anybody know why unit tests are difficult in TypeScript?
type StubInstance<T> = {
[P in keyof T]: sinon.SinonStub;
};I thought that has stopped being true for a while now.
PS Assuming that by web app you mean "the backend for web apps". Otherwise Node would be used 'just' for the build process, together with Webpack and friends.
You can find some valuable informations about why Node.js is relevant in this article: http://thenewstack.io/enterprises-embracing-microservices-no...