npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

boilerplate-typescript-rest-docker

v0.0.2

Published

How to use TypeScript & Docker building a REST service with debugging enabled (e.g. WebStorm or VSCode).

Downloads

9

Readme

boilerplate-typescript-rest-docker Build Status

How to use TypeScript & Docker building a REST service with debugging enabled (e.g. WebStorm or VSCode).

Installation

# Clone the directory
$ git clone https://github.com/stefanwalther/boilerplate-typescript-rest-docker

# Install the local dependencies
# - Not necessary if you just want to use/test the docker containers

$ npm install

The Development Workflow

The development environment contains the following:

  • A docker container called rest-service containing the REST server as defined in ./src.
  • The REST services is exposed at http://localhost:8000.
  • Watcher (using nodemonhttp://nodemon.io/ ): As soon as you make changes to the ./src folder, the TypeScript files will be transpiled again and the server restarted.
    • So you can run your integration tests against your local rest-service container, which is after any change immediately up to date.
  • Remote debugging enabled through port 5858.

Run the Development Environment

$ docker-compose --f=./docker/docker-compose.dev.yml up

This will give you all of the above described.

Debugging in WebStorm

Assuming that rest-service itself could rely on other services it makes sense just to spin up the development environment:

$ docker-compose --f=./docker/docker-compose.dev.yml up

So you can run your integration tests against http://localhost8000 The rest-service will be updated every time you make updates to the ./src folder.

If you want to debug the rest-service (e.g. when hitting integration tests against the rest-service) this is the configuration being used in this example:

Create a remote debugger

  • ./docker/docker-compose.dev.yml opens the port 5858 for the debugger, so let's connect to it:

Remote Debugger Configuration in WebStorm

Running Unit Tests

Running the unit test in this scenario is straight-forward, just configure WebStorm as follows. (This will not use the container, just directly test the transpiled TypeScript code).

Configure Unit Tests in WebStorm

Most of the settings should be default, except:

  • Extra mocha options: --require ./test/mocha.conf.js
  • Test file patterns: ./test/unit/**/*.spec.ts

Hit the Debugger (That's the trick!!!)

If you want to debug the rest-service (running inside the container), follow these steps:

1) Set up the remote debugger as shown above
2) Run the development environment docker-compose --f=./docker/docker-compose.dev.yml up

3) Set up the integration tests in Mocha:

The configuration is very similar to the unit tests:

Configure Integration Tests in WebStorm

  • Extra mocha options: --require ./test/mocha.conf.js
  • Test file patterns: ./test/integration/**/*.spec.ts

4) Start your "Remote Debugger"

Start Remote Debugger in WebStorm

Here come the trick. If you don't see your ./*.ts files (as in the screenshot below), then the sourcemaps as created by tsc have not been resolved by WebStorm. (That's a bug and I'll file it as such).

Watch the Tool's Panel in WebStorm

There's a neat trick, though a bit annoying, but i works:

Just press the "Re-Run Debugger" icon, and then you should see the ./*.ts files as in the second following screenshot.

Watch the Tool's Panel  in WebStorm

Watch the Tool's Panel  in WebStorm

Once this works you can hit any breakpoint in the rest-service (e.g. by running test:integration in Run mode) and it will be hit:

Debugging WebStorm

Continuous Integration

To simulate the Continuous Integration script run the following

$ bash ./docker/docker-ci.sh

An example how to implement CI using travis is provided, have a look at the .travis.yml file and the result .

Credits

This solutions is very much inspired by the following two articles:

  • https://hharnisc.github.io/2016/06/19/integration-testing-with-docker-compose.html
  • https://medium.com/@creynders/debugging-node-apps-in-docker-containers-through-webstorm-ae3f8efe554d#.mplfu74fz

Another very interesting read in that context:

  • https://blog.hospodarets.com/nodejs-debugging-in-chrome-devtools