ts-loader: webpack hangs when declaration:true without creating d.ts files

A response to this issue would be appreciated, even if it’s just to say “no progress made yet” - I submitted a fix for this nearly 3 months ago and none of the maintainers seem to have looked at it.

In the meantime, I’d recommend switching to awesome-typescript-loader if this functionality is essential to you, their implementation of it works fine.

Okay, I think I’ve figured it out!

See line 493 onwards in index.ts - I logged out Object.keys(compilation.assets) after the .forEach completes, and got the following (which is obviously cut down for brevity):

[
    "./img/sprite_2x.png",
    "./img/logo.png",
    "./img/logoWhite.png",
    "app.bundle.js",
    "C:/projects/sm-web/src/loginRedirect.d.ts",
    "C:/projects/sm-web/src/main.d.ts",
]

The keys of the declaration files are being set to be full paths, rather than relative paths, which doesn’t seem to be how the other loaders work. Sure enough, as soon as I replaced compilation.assets[declarationFile.name] with compilation.assets[path.relative(process.cwd(), declarationFile.name)], the declaration files started being output without any issue. I took a look at awesome-typescript-loader’s source for comparison, and this is in fact the same approach they take.

I’ll submit a pull request for this fix this afternoon!

Shipped with 0.9

‘Hang at emit: 95%’ occurs only on windows. On linux and Mac, it does not hang, but generate d.ts under the directory dist - that is defined at path in webpack.config.js - with creating full path of the src directory. That’s why it hangs because full path of windows include ‘C:’ or something and : is invalid as a filename.

And still it is not the desired result. It should generate d.ts on original .ts directory.

If you remove path entry from webpack.config.js,

output: {
    // path: path.join(__dirname, '/dist'),
    filename: outputFile,
   ...

you will get .d.ts at the desired place. (However final js files will not go to dist/ but generated on top.)

Definitely sounds like some kind of bug. I’ll take a look.

Happy to help!

Did you get anywhere with looking into this? No hurry, of course, it’d just make my life a lot easier if I could get it working! For reference, the end result I’m hoping for is effectively this: https://github.com/angular/angular/issues/5796#issuecomment-195478422. That said, I don’t know how feasible it is to get that working through Webpack.

EDIT: My tsconfig.json is:

{
  "compilerOptions": {
    "target": "es2015",
    "moduleResolution": "node",
    "allowSyntheticDefaultImports": true,
    "sourceMap": false
  },

  "exclude": [
    "typings/main.d.ts",
    "typings/main",
    "node_modules"
  ]
}

Yup - you can see reference on the releases page here. It was essentially fixed in 2 stages:

https://github.com/TypeStrong/ts-loader/commit/3bb0fec73a2fab47953b51d256f0f5378f236ad1

Which caused problems for some people and lead to:

https://github.com/TypeStrong/ts-loader/pull/307/commits/03c8da946d361779dc788ce1f51a779cebf93eb6

@johnnyreilly Way to step up!

Hi @17cupsofcoffee,

Thanks for your efforts so far! I apologise for the radio silence. I’m not massively acquainted with the ts-loader codebase but I’m going to make an effort to try and get things back on track. I’m just looking at the tests now.

I’m having the same issue - as soon as I add declaration: true to my compilerOptions, Webpack hangs at ‘95% emit’. I’m not using my IDE to emit files either, just going TypeScript -> Webpack -> JavaScript.