Is ts-loader adding d.ts files as a dependency to the bundle?

[guncha]

I'm running into a situation where changes to the d.ts files are not getting picked up by Webpack during incremental building. Using webpack 1.12.3 with ts-loader 0.6.1. The loader config:

{
  test: /\.tsx?$/,
  exclude: /node_modules/,
  loader: 'babel-loader?plugins[]=babel-relay-plugin-wrapper&cacheDirectory!ts-loader'
}

Webpack is invoked using the Node.js API (not watching).

[jbrantly]

They certainly should get picked up. See https://github.com/TypeStrong/ts-loader/tree/master/test/declarationWatch for a simple example. There were some changes introduced in 0.6.1 that possibly could affect this. Could you try v0.6.0?

[guncha]

Just tried with 0.6.0 and yes, it works fine. Anything I can do?

[guncha]

Actually, I take that back. Changes to a d.ts file with 0.6.0 causes a rebuild, but the changes are still not picked up. Basically, I can mess up my d.ts files and it will still compile fine with the cached version.

[jbrantly]

Changes to a d.ts file with 0.6.0 causes a rebuild

Do changes in 0.6.1 also cause a rebuild or no?

but the changes are still not picked up. Basically, I can mess up my d.ts files and it will still compile fine with the cached version.

Just to be clear - are you saying that errors resulting from your changes aren't reported? Or are you saying errors are reported but the bundle is still being built despite the errors?

How are you referencing the .d.ts in question - through a tripleslash reference or through tsconfig.json?

[guncha]

Changes with 0.6.1 don't cause a rebuild (the module is not emitted) while they do with 0.6.0. In both cases, though, the changes in a d.ts are not actually picked up. So, if the first compile resulted in an error, every consecutive compile will have the same error even if I fix the error in the typings.

I'm using a tsconfig.json:

{
  "compilerOptions": {
    "jsx": "react",
    "target": "ES6"
  },
  "exclude": [
    "node_modules"
  ]
}

All .tsx? files are included by default.

[jbrantly]

Opened #110 to fix this.

[jbrantly]

Published in v0.7.2