mirror of
https://github.com/microsoft/TypeScript-Node-Starter.git
synced 2025-11-08 16:17:37 +00:00
Improvements to the README from PR #145
This commit is contained in:
179
README.md
179
README.md
@@ -1,14 +1,33 @@
|
||||
# TypeScript Node Starter
|
||||
|
||||
[](https://david-dm.org/Microsoft/TypeScript-Node-Starter) [](https://travis-ci.org/Microsoft/TypeScript-Node-Starter)
|
||||
[](https://david-dm.org/Microsoft/TypeScript-Node-Starter) [](https://travis-ci.org/Microsoft/TypeScript-Node-Starter)
|
||||
|
||||
**Live Demo**: [https://typescript-node-starter.azurewebsites.net/](https://typescript-node-starter.azurewebsites.net/)
|
||||
|
||||

|
||||
|
||||
The main purpose of this repository is to show a good end-to-end project setup and workflow for writing Node code in TypeScript.
|
||||
We will try to keep this as up-to-date as possible, but community contributions and recommendations for improvements are encouraged and will be most welcome.
|
||||
We will try to keep this as up-to-date as possible, but community contributions and recommendations for improvements are encouraged and will be most welcome.
|
||||
|
||||
# Table of contents:
|
||||
|
||||
- [Pre-reqs](#pre-reqs)
|
||||
- [Getting started](#getting-started)
|
||||
- [Deploying the app](#deploying-the-app)
|
||||
- [Pre-reqs](#pre-reqs-1)
|
||||
- [Deploying to Azure App Service](#deploying-to-azure-app-service)
|
||||
- [TypeScript + Node](#typescript--node)
|
||||
- [Getting TypeScript](#getting-typescript)
|
||||
- [Project Structure](#project-structure)
|
||||
- [Building the project](#building-the-project)
|
||||
- [Type Definition (`.d.ts`) Files](#type-definition-dts-files)
|
||||
- [Debugging](#debugging)
|
||||
- [Testing](#testing)
|
||||
- [TSLint](#tslint)
|
||||
- [Dependencies](#dependencies)
|
||||
- [`dependencies`](#dependencies-1)
|
||||
- [`devDependencies`](#devdependencies)
|
||||
- [Hackathon Starter Project](#hackathon-starter-project)
|
||||
|
||||
# Pre-reqs
|
||||
To build and run this app locally you will need a few things:
|
||||
@@ -44,7 +63,7 @@ npm start
|
||||
```
|
||||
Or, if you're using VS Code, you can use `cmd + shift + b` to run the default build task (which is mapped to `npm run build`), and then you can use the command palette (`cmd + shift + p`) and select `Tasks: Run Task` > `npm: start` to run `npm start` for you.
|
||||
|
||||
> **Note on editors!** - TypeScript has great support in [every editor](http://www.typescriptlang.org/index.html#download-links), but this project has been pre-configured for use with [VS Code](https://code.visualstudio.com/).
|
||||
> **Note on editors!** - TypeScript has great support in [every editor](http://www.typescriptlang.org/index.html#download-links), but this project has been pre-configured for use with [VS Code](https://code.visualstudio.com/).
|
||||
Throughout the README We will try to call out specific places where VS Code really shines or where this project has been setup to take advantage of specific features.
|
||||
|
||||
Finally, navigate to `http://localhost:3000` and you should see the template being served and rendered locally!
|
||||
@@ -58,23 +77,23 @@ In this section, I'll walk you through how to deploy this app to Azure App Servi
|
||||
The Azure free tier gives you plenty of resources to play around with including up to 10 App Service instances, which is what we will be using.
|
||||
- [**VS Code**](https://code.visualstudio.com/) - We'll be using the interface provided by VS Code to quickly deploy our app.
|
||||
- [**Azure App Service VS Code extension**](https://marketplace.visualstudio.com/items?itemName=ms-azuretools.vscode-azureappservice) - In VS Code, search for `Azure App Service` in the extension marketplace (5th button down on the far left menu bar), install the extension, and then reload VS Code.
|
||||
- **Create a cloud database** -
|
||||
- **Create a cloud database** -
|
||||
For local development, running MongoDB on localhost is fine, however once we deploy we need a database with high availability.
|
||||
The easiest way to achieve this is by using a managed cloud database.
|
||||
There are many different providers, but the easiest one to get started with is [MongoLab](#mlab).
|
||||
|
||||
### <a name="mlab"></a> Create a managed MongoDB with MongoLab
|
||||
1. Navigate to [mLab's Website](https://mlab.com/), sign up for a free account, and then log in.
|
||||
1. Navigate to [MongoLab's Website](https://mlab.com/), sign up for a free account, and then log in.
|
||||
2. In the **MongoDB Deployments** section, click the **Create New** button.
|
||||
3. Select any provider (I recommend **Microsoft Azure** as it provides an easier path to upgrading to globally distributed instances later).
|
||||
4. Select **Sandbox** to keep it free unless you know what you're doing, and hit **Continue**.
|
||||
5. Select a region (I recommend the region geographically closest to your app's users).
|
||||
6. Add a name, click **Continue** again, and finally **Submit Order**.
|
||||
7. Once your new database is created, select it from the **MongoDB Deployments** section.
|
||||
8. Create a user by selecting the **User** tab, clicking the **Add database user** button, adding a username and password, and then clicking **Create**.
|
||||
8. Create a user by selecting the **User** tab, clicking the **Add database user** button, adding a username and password, and then clicking **Create**.
|
||||
A user account is required to connect to the database, so remember these values because you will need them as part of your connection string.
|
||||
9. Copy the connection string from the top of the page, it should look like this: `mongodb://<dbuser>:<dbpassword>@ds036069.mlab.com:36069/test-asdf`
|
||||
and replace `<dbUser>` and `<dbpassword>` with the credentials you just created.
|
||||
and replace `<dbUser>` and `<dbpassword>` with the credentials you just created.
|
||||
Back in your project, open your `.env` file and update `MONGODB_URI` with your new connection string.
|
||||
> NOTE! - If you don't have an `.env` file yet, rename `.env.example` to `.env` and follow the comments to update the values in that file.
|
||||
10. **Success!**
|
||||
@@ -101,10 +120,10 @@ Deploying from VS Code can be broken into the following steps:
|
||||
5. Paste in the code that is on your clipboard.
|
||||
6. Go back to VS Code, you should now be signed in.
|
||||
You can confirm that everything worked by seeing your Azure subscription listed in the Azure App Service section of the explorer window.
|
||||
Additionally you should see the email associated with your account listed in the status bar at the bottom of VS Code.
|
||||
Additionally you should see the email associated with your account listed in the status bar at the bottom of VS Code.
|
||||
|
||||
### Build the app
|
||||
Building the app locally is required before a zip deploy because the App Service won't execute build tasks.
|
||||
Building the app locally is required to generate a zip to deploy because the App Service won't execute build tasks.
|
||||
Build the app however you normally would:
|
||||
- `ctrl + shift + b` - kicks off default build in VS Code
|
||||
- execute `npm run build` from a terminal window
|
||||
@@ -118,9 +137,9 @@ If you haven't changed the name, this will be `TypeScript-Node-Starter`.
|
||||
5. Choose `Create New Web App`
|
||||
6. Enter a globally unique name -
|
||||
This will be part of the URL that azure generates so it has to be unique, but if you're planning on adding a custom domain later, it's not that important. I usually just add random numbers to the end of the app name, ie. typescript-node-starter-15121214.
|
||||
7. Choose a resource group -
|
||||
If you don't know what this is, just create a new one.
|
||||
If you have lots of cloud resources that should be logically grouped together (think an app service and a database that supports that app) then you would want to put them in the same resource group.
|
||||
7. Choose a resource group -
|
||||
If you don't know what this is, just create a new one.
|
||||
If you have lots of cloud resources that should be logically grouped together (think an app service and a database that supports that app) then you would want to put them in the same resource group.
|
||||
This can always be updated later though.
|
||||
If you create a new resource group, you'll also be prompted to pick a location for that group.
|
||||
Pick something geographically close to where your users are.
|
||||
@@ -134,14 +153,14 @@ If you don't know what you want, choose whatever the current LTS build is.
|
||||
All of this is powered by the [Azure CLI](https://docs.microsoft.com/en-us/cli/azure/overview?view=azure-cli-latest) and can be easily replicated if you decide you want to customize this process.
|
||||
This deployment is not the fastest option (but it is the easiest!). We are literally bundling everything in your project (including the massive node_modules folder) and uploading it to our Azure app service. Times will vary, but as a baseline, my deployment took roughly 6 minutes.
|
||||
12. Add `NODE_ENV` environment variable - In the App Service section of the explorer window, expand the newly created service, right click on **Application Settings**, select **Add New Settings...**, and add `NODE_ENV` as the key and `production` as the value.
|
||||
This setting determines which database to point to.
|
||||
This setting determines which database to point to.
|
||||
If you haven't created a cloud database yet, see [the setup instructions](#mlab).
|
||||
13. Profit! If everything worked you should see a page that looks like this: [TypeScript Node Starter Demo Site](https://typescript-node-starter.azurewebsites.net/)
|
||||
|
||||
### Troubleshooting failed deployments
|
||||
Deployment can fail for various reasons, if you get stuck with a page that says *Service Unavailable* or some other error, [open an issue](https://github.com/Microsoft/TypeScript-Node-Starter/issues/new) and I'll try to help you resolve the problems.
|
||||
|
||||
# TypeScript + Node
|
||||
# TypeScript + Node
|
||||
In the next few sections I will call out everything that changes when adding TypeScript to an Express project.
|
||||
Note that all of this has already been setup for this project, but feel free to use this as a reference for converting other Node.js projects to TypeScript.
|
||||
|
||||
@@ -151,14 +170,14 @@ TypeScript itself is simple to add to any project with `npm`.
|
||||
npm install -D typescript
|
||||
```
|
||||
If you're using VS Code then you're good to go!
|
||||
VS Code will detect and use the TypeScript version you have installed in your `node_modules` folder.
|
||||
For other editors, make sure you have the corresponding [TypeScript plugin](http://www.typescriptlang.org/index.html#download-links).
|
||||
VS Code will detect and use the TypeScript version you have installed in your `node_modules` folder.
|
||||
For other editors, make sure you have the corresponding [TypeScript plugin](http://www.typescriptlang.org/index.html#download-links).
|
||||
|
||||
## Project Structure
|
||||
The most obvious difference in a TypeScript + Node project is the folder structure.
|
||||
In a TypeScript project, it's best to have separate _source_ and _distributable_ files.
|
||||
TypeScript (`.ts`) files live in your `src` folder and after compilation are output as JavaScript (`.js`) in the `dist` folder.
|
||||
The `test` and `views` folders remain top level as expected.
|
||||
The `test` and `views` folders remain top level as expected.
|
||||
|
||||
The full folder structure of this app is explained below:
|
||||
|
||||
@@ -188,31 +207,30 @@ The full folder structure of this app is explained below:
|
||||
| tslint.json | Config settings for TSLint code style checking |
|
||||
|
||||
## Building the project
|
||||
It is rare for JavaScript projects not to have some kind of build pipeline these days. However, Node projects typically have the least amount of build configuration.
|
||||
It is rare for JavaScript projects not to have some kind of build pipeline these days, however Node projects typically have the least amount of build configuration.
|
||||
Because of this I've tried to keep the build as simple as possible.
|
||||
If you're concerned about compile time, the main watch task takes ~2s to refresh.
|
||||
|
||||
### Configuring TypeScript compilation
|
||||
TypeScript uses the file `tsconfig.json` to adjust project compile options.
|
||||
Let's dissect this project's `tsconfig.json`, starting with the `compilerOptions` which details how your project is compiled.
|
||||
|
||||
Let's dissect this project's `tsconfig.json`, starting with the `compilerOptions` which details how your project is compiled.
|
||||
```json
|
||||
"compilerOptions": {
|
||||
"module": "commonjs",
|
||||
"esModuleInterop": true,
|
||||
"target": "es6",
|
||||
"noImplicitAny": true,
|
||||
"moduleResolution": "node",
|
||||
"sourceMap": true,
|
||||
"outDir": "dist",
|
||||
"baseUrl": ".",
|
||||
"paths": {
|
||||
"*": [
|
||||
"node_modules/*",
|
||||
"src/types/*"
|
||||
]
|
||||
}
|
||||
},
|
||||
"compilerOptions": {
|
||||
"module": "commonjs",
|
||||
"esModuleInterop": true,
|
||||
"target": "es6",
|
||||
"noImplicitAny": true,
|
||||
"moduleResolution": "node",
|
||||
"sourceMap": true,
|
||||
"outDir": "dist",
|
||||
"baseUrl": ".",
|
||||
"paths": {
|
||||
"*": [
|
||||
"node_modules/*",
|
||||
"src/types/*"
|
||||
]
|
||||
}
|
||||
},
|
||||
```
|
||||
|
||||
| `compilerOptions` | Description |
|
||||
@@ -227,15 +245,13 @@ Let's dissect this project's `tsconfig.json`, starting with the `compilerOptions
|
||||
| `"baseUrl": "."` | Part of configuring module resolution. See [path mapping section](#installing-dts-files-from-definitelytyped) |
|
||||
| `paths: {...}` | Part of configuring module resolution. See [path mapping section](#installing-dts-files-from-definitelytyped) |
|
||||
|
||||
|
||||
|
||||
The rest of the file defines the TypeScript project context.
|
||||
The rest of the file define the TypeScript project context.
|
||||
The project context is basically a set of options that determine which files are compiled when the compiler is invoked with a specific `tsconfig.json`.
|
||||
In this case, we use the following to define our project context:
|
||||
In this case, we use the following to define our project context:
|
||||
```json
|
||||
"include": [
|
||||
"src/**/*"
|
||||
]
|
||||
"include": [
|
||||
"src/**/*"
|
||||
]
|
||||
```
|
||||
`include` takes an array of glob patterns of files to include in the compilation.
|
||||
This project is fairly simple and all of our .ts files are under the `src` folder.
|
||||
@@ -278,7 +294,7 @@ This is great because once you have a `.d.ts` file, TypeScript can type check th
|
||||
The TypeScript community actively shares all of the most up-to-date `.d.ts` files for popular libraries on a GitHub repository called [DefinitelyTyped](https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types).
|
||||
Making sure that your `.d.ts` files are setup correctly is super important because once they're in place, you get an incredible amount of high quality type checking (and thus bug catching, IntelliSense, and other editor tools) for free.
|
||||
|
||||
> **Note!** Because we're using `"noImplicitAny": true`, we are required to have a `.d.ts` file for **every** library we use. While you could set `noImplicitAny` to `false` to silence errors about missing `.d.ts` files, it is a best practice to have a `.d.ts` file for every library. (Even if the `.d.ts` file is [basically empty!](#writing-a-dts-file))
|
||||
> **Note!** Because we're using `"noImplicitAny": true`, we are required to have a `.d.ts` file for **every** library we use. While you could set `noImplicitAny` to `false` to silence errors about missing `.d.ts` files, it is a best practice to have a `.d.ts` file for every library. (Even if the `.d.ts` file is [basically empty!](#writing-a-dts-file))
|
||||
|
||||
### Installing `.d.ts` files from DefinitelyTyped
|
||||
For the most part, you'll find `.d.ts` files for the libraries you are using on DefinitelyTyped.
|
||||
@@ -288,7 +304,7 @@ For example, if we want the `.d.ts` file for jQuery, we can do so with `npm inst
|
||||
> **Note!** Be sure to add `--save-dev` (or `-D`) to your `npm install`. `.d.ts` files are project dependencies, but only used at compile time and thus should be dev dependencies.
|
||||
|
||||
In this template, all the `.d.ts` files have already been added to `devDependencies` in `package.json`, so you will get everything you need after running your first `npm install`.
|
||||
Once `.d.ts` files have been installed using npm, you should see them in your `node_modules/@types` folder.
|
||||
Once `.d.ts` files have been installed using npm, you should see them in your `node_modules/@types` folder.
|
||||
The compiler will always look in this folder for `.d.ts` files when resolving JavaScript libraries.
|
||||
|
||||
### What if a library isn't on DefinitelyTyped?
|
||||
@@ -309,7 +325,7 @@ In the `tsconfig.json` for this project you'll see the following:
|
||||
}
|
||||
```
|
||||
This tells the TypeScript compiler that in addition to looking in `node_modules/@types` for every import (`*`) also look in our own `.d.ts` file location `<baseUrl>` + `src/types/*`.
|
||||
So when we write something like:
|
||||
So when we write something like:
|
||||
```ts
|
||||
import * as flash from "express-flash";
|
||||
```
|
||||
@@ -318,7 +334,7 @@ First the compiler will look for a `d.ts` file in `node_modules/@types` and then
|
||||
#### Using `dts-gen`
|
||||
Unless you are familiar with `.d.ts` files, I strongly recommend trying to use the tool [dts-gen](https://github.com/Microsoft/dts-gen) first.
|
||||
The [README](https://github.com/Microsoft/dts-gen#dts-gen-a-typescript-definition-file-generator) does a great job explaining how to use the tool, and for most cases, you'll get an excellent scaffold of a `.d.ts` file to start with.
|
||||
In this project, `bcrypt-nodejs.d.ts`, `fbgraph.d.ts`, and `lusca.d.ts` were all generated using `dts-gen`.
|
||||
In this project, `bcrypt-nodejs.d.ts`, `fbgraph.d.ts`, and `lusca.d.ts` were all generated using `dts-gen`.
|
||||
|
||||
#### Writing a `.d.ts` file
|
||||
If generating a `.d.ts` using `dts-gen` isn't working, [you should tell me about it first](https://www.surveymonkey.com/r/LN2CV82), but then you can create your own `.d.ts` file.
|
||||
@@ -327,8 +343,7 @@ If you just want to silence the compiler for the time being, create a file calle
|
||||
```ts
|
||||
declare module "<some-library>";
|
||||
```
|
||||
|
||||
If you want to invest some time into making a great `.d.ts` file that will give you great type checking and IntelliSense, the TypeScript website has great [docs on authoring `.d.ts` files](http://www.typescriptlang.org/docs/handbook/declaration-files/introduction.html).
|
||||
If you want to invest some time into making a great `.d.ts` file that will give you great type checking and IntelliSense, the TypeScript website has great [docs on authoring `.d.ts` files](http://www.typescriptlang.org/docs/handbook/declaration-files/introduction.html).
|
||||
|
||||
#### Contributing to DefinitelyTyped
|
||||
The reason it's so easy to get great `.d.ts` files for most libraries is that developers like you contribute their work back to DefinitelyTyped.
|
||||
@@ -343,7 +358,7 @@ In general if you stick to the following steps you should have minimal `.d.ts` i
|
||||
2. If the library has a `.d.ts` file on DefinitelyTyped, the install will succeed and you are done.
|
||||
If the install fails because the package doesn't exist, continue to step 3.
|
||||
3. Make sure you project is [configured for supplying your own `d.ts` files](#setting-up-typescript-to-look-for-dts-files-in-another-folder)
|
||||
4. Try to [generate a `.d.ts` file with dts-gen](#using-dts-gen).
|
||||
4. Try to [generate a `.d.ts` file with dts-gen](#using-dts-gen).
|
||||
If it succeeds, you are done.
|
||||
If not, continue to step 5.
|
||||
5. Create a file called `<some-library>.d.ts` in your `types` folder.
|
||||
@@ -358,35 +373,34 @@ declare module "<some-library>";
|
||||
Debugging TypeScript is exactly like debugging JavaScript with one caveat, you need source maps.
|
||||
|
||||
### Source maps
|
||||
Source maps allow you to drop break points in your TypeScript source code and have that break point be hit by the JavaScript that is being executed at runtime.
|
||||
Source maps allow you to drop break points in your TypeScript source code and have that break point be hit by the JavaScript that is being executed at runtime.
|
||||
|
||||
> **Note!** - Source maps aren't specific to TypeScript.
|
||||
Anytime JavaScript is transformed (transpiled, compiled, optimized, minified, etc) you need source maps so that the code that is executed at runtime can be _mapped_ back to the source that generated it.
|
||||
|
||||
The best part of source maps is, when configured correctly, you don't even know they exist! So let's take a look at how we do that in this project.
|
||||
The best part of source maps is when configured correctly, you don't even know they exist! So let's take a look at how we do that in this project.
|
||||
|
||||
#### Configuring source maps
|
||||
First you need to make sure your `tsconfig.json` has source map generation enabled:
|
||||
```json
|
||||
"compilerOptions" {
|
||||
"sourceMap": true
|
||||
}
|
||||
}
|
||||
```
|
||||
With this option enabled, next to every `.js` file that the TypeScript compiler outputs there will be a `.map.js` file as well.
|
||||
This `.map.js` file provides the information necessary to map back to the source `.ts` file while debugging.
|
||||
|
||||
> **Note!** - It is also possible to generate "inline" source maps using `"inlineSourceMap": true`.
|
||||
This is more common when writing client side code because some bundlers need inline source maps to preserve the mapping through the bundle.
|
||||
Because we are writing Node.js code, we don't have to worry about this.
|
||||
Because we are writing Node.js code, we don't have to worry about this.
|
||||
|
||||
### Using the debugger in VS Code
|
||||
Debugging is one of the places where VS Code really shines over other editors.
|
||||
Node.js debugging in VS Code is easy to setup and even easier to use.
|
||||
Node.js debugging in VS Code is easy to setup and even easier to use.
|
||||
This project comes pre-configured with everything you need to get started.
|
||||
|
||||
When you hit `F5` in VS Code, it looks for a top level `.vscode` folder with a `launch.json` file.
|
||||
In this file, you can tell VS Code exactly what you want to do:
|
||||
|
||||
```json
|
||||
{
|
||||
"type": "node",
|
||||
@@ -418,27 +432,27 @@ npm install -D jest ts-jest
|
||||
Jest's configuration lives in `jest.config.js`, so let's open it up and add the following code:
|
||||
```js
|
||||
module.exports = {
|
||||
globals: {
|
||||
'ts-jest': {
|
||||
tsConfigFile: 'tsconfig.json'
|
||||
}
|
||||
},
|
||||
moduleFileExtensions: [
|
||||
'ts',
|
||||
'js'
|
||||
],
|
||||
transform: {
|
||||
'^.+\\.(ts|tsx)$': './node_modules/ts-jest/preprocessor.js'
|
||||
},
|
||||
testMatch: [
|
||||
'**/test/**/*.test.(ts|js)'
|
||||
],
|
||||
testEnvironment: 'node'
|
||||
globals: {
|
||||
'ts-jest': {
|
||||
tsConfigFile: 'tsconfig.json'
|
||||
}
|
||||
},
|
||||
moduleFileExtensions: [
|
||||
'ts',
|
||||
'js'
|
||||
],
|
||||
transform: {
|
||||
'^.+\\.(ts|tsx)$': './node_modules/ts-jest/preprocessor.js'
|
||||
},
|
||||
testMatch: [
|
||||
'**/test/**/*.test.(ts|js)'
|
||||
],
|
||||
testEnvironment: 'node'
|
||||
};
|
||||
```
|
||||
Basically we are telling Jest that we want it to consume all files that match the pattern `"**/test/**/*.test.(ts|js)"` (all `.test.ts`/`.test.js` files in the `test` folder), but we want to preprocess the `.ts` files first.
|
||||
Basically we are telling Jest that we want it to consume all files that match the pattern `"**/test/**/*.test.(ts|js)"` (all `.test.ts`/`.test.js` files in the `test` folder), but we want to preprocess the `.ts` files first.
|
||||
This preprocess step is very flexible, but in our case, we just want to compile our TypeScript to JavaScript using our `tsconfig.json`.
|
||||
This all happens in memory when you run the tests, so there are no output `.js` test files for you to manage.
|
||||
This all happens in memory when you run the tests, so there are no output `.js` test files for you to manage.
|
||||
|
||||
### Running tests
|
||||
Simply run `npm run test`.
|
||||
@@ -483,6 +497,7 @@ To enhance your development experience while working in VSCode we also provide y
|
||||
# Dependencies
|
||||
Dependencies are managed through `package.json`.
|
||||
In that file you'll find two sections:
|
||||
|
||||
## `dependencies`
|
||||
|
||||
| Package | Description |
|
||||
@@ -514,19 +529,19 @@ In that file you'll find two sections:
|
||||
|
||||
## `devDependencies`
|
||||
|
||||
| Package | Description |
|
||||
| ------------------------------- | --------------------------------------------------------------------- |
|
||||
| Package | Description |
|
||||
| ------------------------------- | ---------------------------------------------------------------------- |
|
||||
| @types | Dependencies in this folder are `.d.ts` files used to provide types |
|
||||
| chai | Testing utility library that makes it easier to write tests |
|
||||
| concurrently | Utility that manages multiple concurrent tasks. Used with npm scripts |
|
||||
| jest | Testing library for JavaScript. |
|
||||
| chai | Testing utility library that makes it easier to write tests |
|
||||
| concurrently | Utility that manages multiple concurrent tasks. Used with npm scripts |
|
||||
| jest | Testing library for JavaScript. |
|
||||
| node-sass | Allows to compile .scss files to .css |
|
||||
| nodemon | Utility that automatically restarts node process when it crashes |
|
||||
| supertest | HTTP assertion library. |
|
||||
| nodemon | Utility that automatically restarts node process when it crashes |
|
||||
| supertest | HTTP assertion library. |
|
||||
| ts-jest | A preprocessor with sourcemap support to help use TypeScript with Jest.|
|
||||
| ts-node | Enables directly running TS files. Used to run `copy-static-assets.ts` |
|
||||
| tslint | Linter (similar to ESLint) for TypeScript files |
|
||||
| typescript | JavaScript compiler/type checker that boosts JavaScript productivity |
|
||||
| typescript | JavaScript compiler/type checker that boosts JavaScript productivity |
|
||||
|
||||
To install or update these dependencies you can use `npm install` or `npm update`.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user