Every day now we hear that more people are using typescript. Some of us grew up with types and some of us never knew types. I'm not going to argue the toss. But we can choose either now. Typescript is easy I'm told. Well like all things it is easy to do the basic hello world but how do you setup a proper project?
The intent of this repo is simply to put a stake in the ground and create an NPM module using typescript that could be copied as a starter project.
Yes there are sample projects on the typescriptlang site but having had a good look I am not sure they fit the use case I want exactly.
Here are my goals.
- typescript transpilation via @babel/preset-typescript
- eslint rather than tslint as that is how MS are moving
- nyc code coverage
- typescript prettier
- definition file, create a definition file that can be used when this module is published
- publishable package with a declarations file
- build/test/lint on osx, linux and windows via travis
I think this is the way the community is going. I'm not sure of course. Eslint is very widely used already. This is a good place to describe how to set it up. The key learning I had when setting it up was that typescript linting required a different parser. A plugin will also be required. The typescript have decided this the way forwards and the following links support this.
This little gem is from the parse repo.
"There is sometimes an incorrect assumption that the parser itself
is what does everything necessary to facilitate the use of ESLint
with TypeScript. In actuality, it is the combination of the parser
and one or more plugins which allow you to maximize your usage of
ESLint with TypeScript"
quote from the road map
"Given this, our editor team will be focusing on leveraging ESLint rather than duplicating work. For
scenarios that ESLint currently doesn't cover (e.gl. semantic linting or program-wide linting),
we'll be working on sending contributions to bring ESLint's TypeScript support to parity with TSLint.
As an initial testbed of how this works in practice, we'll be switching the TypeScript repository over
to using ESLint, and sending any new rules upstream."
After having looked long and hard at jest I feel that Jest is terrific but all the test frameworks do a good job. There are lots of choices I have decided to write unit tests in both mocha and jest (this is an example project). Of course jest includes coverage. So for mocha you would need nyc/istanbul.
| test framework | file extension |
|---|---|
| mocha | *.spec.ts |
| jest | *.test.ts |
I am a firm believer in choice. If you use webstorm the debugging just works. For vscode here are my launch.json settings
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"name": "Debug Jest Tests",
"type": "node",
"request": "launch",
"runtimeArgs": [
"--inspect-brk",
"${workspaceRoot}/node_modules/.bin/jest",
"--runInBand"
],
"console": "integratedTerminal",
"internalConsoleOptions": "neverOpen",
"port": 9229
},
{
"type": "node",
"request": "launch",
"name": "Mocha Tests",
"program": "${workspaceFolder}/node_modules/mocha/bin/_mocha",
"args": [
"-r",
"./src/register.js",
"--colors",
"${workspaceFolder}/src/**/*.spec.ts"
],
"env": {
"NODE_ENV": "test"
},
"internalConsoleOptions": "openOnSessionStart",
"runtimeArgs": [
]
}
]
}
Well jest uses istanbul under the covers so you may as well just use nyc You can delete this and the mocha dependencies too if you go for jest.
Well under the covers it is the same thing, but my prefence is for babel.
The declaration command only emits all the typescript declarations. If you only require one, then you have to emit the definitions to a separate folder and copy the public facing definition to you target lib or dist folder.
I have done my best to make sure this works on
- osx
- linux
- windows