10 ms·

Show HN: Boilerplate for Node.js and TypeScript with Jest tests

33 points by jsynowiec 10y ago

elvinyung 10y ago
Serious question: Is Node.js still a popular choice for developing webapps? I thought that has stopped being true for a while now.
- vnglst 10y ago
  Yes, I think even more so now with the Node Foundation and support for all modern JS syntax (ES6 and beyond). It's being used by mayor players (LinkeIn, Netflix, Medium and Uber to name a few) but also smaller companies (from my personal experience as a freelance developer). 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.
  - jsynowiec 10y ago
    Don't forget about PayPal! You can find some valuable informations about why Node.js is relevant in this article: http://thenewstack.io/enterprises-embracing-microservices-node-js/ http://thenewstack.io/enterprises-embracing-microservices-no...
- debaserab2 10y ago
  What would have replaced it?
- Scarbutt 10y ago
  On the contrary, I would say its popularity is increasing more and more every day.
- pyrophane 10y ago
  Comments such as this one read to me as a dig at a particular technology the commenter does not like. Sort of a more subtle version of "Oh, I didn't realize people were still using THAT."
  - deleted 10y ago
    [deleted]
  - elvinyung 10y ago
    I'm sorry -- it was not intended to be condescending. I really haven't heard much about Node.js for some time, and it's actually really hard to figure that out.
- devdad 10y ago
  My company is almost exclusively using Node for our backends.
- rockostrich 10y ago
  It's still a popular choice. It's very easy to get a simple API or service up and running in production with node, especially if you don't try and include every new library out there for node projects. Express, Rails, and Flask/Django aren't going anywhere anytime soon since they're accessible frameworks in popular scripting languages.
- WayneBro 10y ago
  What gave you that impression and where exactly do you get your information?
vnglst 10y ago
"Unit tests in JavaScript 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?
- Joeri 10y ago
  Typescript is strictly typed, so things that need to look like a type but aren't actually that type, like mocks and spies, can be troublesome.
  - jsynowiec 10y ago
    Exactly. TSC usually complains on all stubs, mocks and spies or it takes massive amounts of time to properly annotate the types. Unit tests quickly don't follow AAA rule, are hard to read (and understand) and the required time investment is not worth it. I find using TypeScript for source code and JavaScript for unit tests much more convenient.
    - Joeri 10y ago
      I've gone both ways. Writing the tests in typescript is doable, but making sure you have good ts declarations for all the unit test libraries is key. I've had good luck with mocha, chai, sinon and their respective @types.
    - scoti 10y ago
      I had the same problem until a recent TS release introducing the keyof feature. You can create a TypeScript type that automatically convert a class definition to stubs. type StubInstance<T> = { [P in keyof T]: sinon.SinonStub; };
vnglst 10y ago
Question for the poster: any general thoughts on why you chose TypeScript instead of Flow Type?
- Joeri 10y ago
  Not the poster, but i just made the same choice. My reasons: - 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.
- jsynowiec 10y ago
  I'm using both TypeScript and Flowtype for my projects, hence the second boilerplate repository on GitHub: https://github.com/jsynowiec/node-flowtype-boilerplate https://github.com/jsynowiec/node-flowtype-boilerplate 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 https://twitter.com/lbljeffmo/status/787692583350829056
  - vnglst 10y ago
    Awesome, thanks!
pyrophane 10y ago
I built a non-trivial webapp in nodejs + Typescript but abandoned it due to these issues: 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.
- Joeri 10y ago
  I just built a 3500 line chatbot with the ms bot framework in typescript and my experience was very different. 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.
  - pyrophane 10y ago
    What you describe would work in dev if you are using your editor's transpiler, but what about production error logging? In my experience that generates JS stack traces and it is a pain to convert those to source-mapped ts stack traces. I know mocha has built-in support for source maps. 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.
roboguy12 10y ago
FWIW, Typescript also has async/await, as of 2.1 (in reference to the Alternative section in your README).
- jsynowiec 10y ago
  The alternative refers to an alternative type checking system - Flowtype. Not that the seconds has the async/await and modules. Both repositories are trying to deliver quite similar tools - type checking, es6 + async/awat + import syntax and linter.

33 points by jsynowiec 10y ago

Serious question: Is Node.js still a popular choice for developing webapps? I thought that has stopped being true for a while now.

vnglst 10y ago
Yes, I think even more so now with the Node Foundation and support for all modern JS syntax (ES6 and beyond). It's being used by mayor players (LinkeIn, Netflix, Medium and Uber to name a few) but also smaller companies (from my personal experience as a freelance developer). 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.
- jsynowiec 10y ago
  Don't forget about PayPal! You can find some valuable informations about why Node.js is relevant in this article: http://thenewstack.io/enterprises-embracing-microservices-node-js/ http://thenewstack.io/enterprises-embracing-microservices-no...
debaserab2 10y ago
What would have replaced it?
Scarbutt 10y ago
On the contrary, I would say its popularity is increasing more and more every day.
pyrophane 10y ago
Comments such as this one read to me as a dig at a particular technology the commenter does not like. Sort of a more subtle version of "Oh, I didn't realize people were still using THAT."
- deleted 10y ago
  [deleted]
- elvinyung 10y ago
  I'm sorry -- it was not intended to be condescending. I really haven't heard much about Node.js for some time, and it's actually really hard to figure that out.
devdad 10y ago
My company is almost exclusively using Node for our backends.
rockostrich 10y ago
It's still a popular choice. It's very easy to get a simple API or service up and running in production with node, especially if you don't try and include every new library out there for node projects. Express, Rails, and Flask/Django aren't going anywhere anytime soon since they're accessible frameworks in popular scripting languages.
WayneBro 10y ago
What gave you that impression and where exactly do you get your information?

vnglst 10y ago

"Unit tests in JavaScript 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?

Joeri 10y ago
Typescript is strictly typed, so things that need to look like a type but aren't actually that type, like mocks and spies, can be troublesome.
- jsynowiec 10y ago
  Exactly. TSC usually complains on all stubs, mocks and spies or it takes massive amounts of time to properly annotate the types. Unit tests quickly don't follow AAA rule, are hard to read (and understand) and the required time investment is not worth it. I find using TypeScript for source code and JavaScript for unit tests much more convenient.
  - Joeri 10y ago
    I've gone both ways. Writing the tests in typescript is doable, but making sure you have good ts declarations for all the unit test libraries is key. I've had good luck with mocha, chai, sinon and their respective @types.
  - scoti 10y ago
    I had the same problem until a recent TS release introducing the keyof feature. You can create a TypeScript type that automatically convert a class definition to stubs. type StubInstance<T> = { [P in keyof T]: sinon.SinonStub; };

vnglst 10y ago

Question for the poster: any general thoughts on why you chose TypeScript instead of Flow Type?

Joeri 10y ago
Not the poster, but i just made the same choice. My reasons: - 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.
jsynowiec 10y ago
I'm using both TypeScript and Flowtype for my projects, hence the second boilerplate repository on GitHub: https://github.com/jsynowiec/node-flowtype-boilerplate https://github.com/jsynowiec/node-flowtype-boilerplate 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 https://twitter.com/lbljeffmo/status/787692583350829056
- vnglst 10y ago
  Awesome, thanks!

pyrophane 10y ago

I built a non-trivial webapp in nodejs + Typescript but abandoned it due to these issues: 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.

Joeri 10y ago
I just built a 3500 line chatbot with the ms bot framework in typescript and my experience was very different. 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.
- pyrophane 10y ago
  What you describe would work in dev if you are using your editor's transpiler, but what about production error logging? In my experience that generates JS stack traces and it is a pain to convert those to source-mapped ts stack traces. I know mocha has built-in support for source maps. 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.

roboguy12 10y ago

FWIW, Typescript also has async/await, as of 2.1 (in reference to the Alternative section in your README).

jsynowiec 10y ago
The alternative refers to an alternative type checking system - Flowtype. Not that the seconds has the async/await and modules. Both repositories are trying to deliver quite similar tools - type checking, es6 + async/awat + import syntax and linter.