Typescript support for @stamp/xxx packages.

[PopGoesTheWza]

In order to offer users proper Typescript support, two options are available:

1. hand crafted .d.ts files for each published package
2. porting current .js source code to Typescript (with incremental build and automatic generation of source maps and .d.ts files

First option might be faster but implies to maintain .js source and .d.ts in sync as code base evolve.

Second option would take longer to achieve but should be easier to maintain in the long run. Caveats is that source code no longer is JavaScript but Typescript. Final code being transpiled (using Typescript or Babel) thus making fine control of the code (slightly) less possible. On the other hand, source Typescript code can benefit from the latest ESnext syntax while still producing JavaScript code compatible with the minimal supported version(es5, es2015, etc.)

[koresar]

Yeah! This package is a great target to be ported to TS! :) That would be amazing. :) Feel free to do it.
Also, I believe that rewriting it with TS is actually faster than adding .d.ts files. :)

[PopGoesTheWza]

I'll start a Typescript branch after most of the other issues are cleared:

• CI Travis no longer shouting
• Node/es version support
• ESlint+Prettier linting

[sambauers]

A bit of a hack, but I've found that this works in package.json to provide types to @stamp/it:

{
  "dependencies: {
    "@stamp/it": "^1.1.0"
  },
  "devDependencies": {
    "@types/stampit": "^4.3.1",
    "@types/stamp__it": "./node_modules/@types/stampit"
  }
}

[char0n]

Or new and more elegant notation:

{
  "dependencies": {
    "@stamp/it": "=1.1.0",
    "@types/stamp__it": "npm:@types/stampit@=4.3.2"
}

NOTE: I believe @types/stamp__it needs to be a dependency and not a devDependency in cases when the code that uses @stam/it + @types/stampit is packages a library and published on npmjs.com.