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

[yaroslavya]

I cloned this repo: https://github.com/adrianhall/example-typescript-webpack
then npm install and if I make npm run prepublish it generates the js files normally, but if I change the declaration to declaration:true in tsconfig.json then npm run prepublish just hangs, right after it generates the .js files. For now whatever I try the ts-loader doesn't generate the d.ts file for my bundle and always hangs after it generated the js files.

I saw the similar issues were fixed some time ago, like with this pull request: https://github.com/TypeStrong/ts-loader/pull/175, but in spite the version was 0.8.2 it doesn't work for me at all

[jbrantly]

You said "it generates the .js files" (I assume you mean corresponding .js files for each .ts file, not the final bundle) which seems strange to me. Typically when using ts-loader you don't want those files and ts-loader itself doesn't generate them. So here's my theory of what is happening to you:

1. You're using a TypeScript aware IDE where when you press save it generates all of the .js files for each .ts file
2. The example project you linked has the ordering of the extensions wrong. It has [ '', '.js', '.ts', '.jsx', '.tsx' ] which means that .js files will be resolved before .ts, so ts-loader is trying to compile the .js files instead.

First you need to fix the ordering of the extenions (.ts stuff should go before .js stuff). Secondly, if you don't want the intermediate .js files from your IDE you can set noEmit to true in your tsconfig.json and then turn it back on for ts-loader specifically using the webpack config override.

[yaroslavya]

I tried the following config settings:
tsconfig.json:
"declaration": true, "module": "commonjs", "noImplicitAny": true, "preserveConstEnums": true, "removeComments": false, "sourceMap": true, "target": "es5", "noEmit": true

webpack.config.js:
module: { loaders: [ { test: /\.tsx?$/, loader: 'ts', exclude: /node_modules/ } ] }
resolve: { root: path.resolve('./src'), extensions: ['.ts', '.js', ''] }
ts:{ compilerOptions:{ noEmit: false } }

If I change the declaration to false in tsconfig.json it works, but of course doesn't produce a d.ts file.
Also I use atom and its configured to not generate any js from ts files, so only webpack generates js from ts files for me. Let me know if I need to upload the whole project on github as the one I referenced doesn't have the fixes.

[17cupsofcoffee]

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.

[yaroslavya]

Yes, exactly, forgot to mention that its 95% for me every time. No matter what project it is.

[jbrantly]

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

[17cupsofcoffee]

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"
  ]
}

[t246246]

'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.)

[17cupsofcoffee]

@t246246 Having the .d.ts end up in my dist folder with the rest of my Webpack output files sounds like how I'd expect it to work, honestly? I don't want definition files being output into my src folder. I might be misunderstanding how things are supposed to work, though. Either way, thanks for the information - can't say I'm surprised it's a Windows issue...

[17cupsofcoffee]

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!

[MeirionHughes]

I've got this issue too; workarounds aren't working for me though.

• "ts-loader": "^0.8.2",
• "typescript": "^1.8.10",
• "webpack": "^2.1.0-beta.17"

[benetis]

+1

[yazla]

I am having exactly the same issue. So is this fixed?

[mijay]

+1

[vidartf]

+1

[sky-coding]

+1

[markjose]

+1

[17cupsofcoffee]

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.

[benetis]

any progress?

[sky-coding]

abandon ship to awesome-typescript-loader

[flyon]

fix proposed by @17cupsofcoffee works for me, just change that one line in node_modules/ts-loader/index.js

[sky-coding]

Changing code inside node_modules is not an option for most people

[markjose]

@flyon that's not an option we have as build server "npm install"s clean before every build. Moved to awesome-typescript-loader

[johnnyreilly]

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.

[17cupsofcoffee]

@johnnyreilly Thanks! I apologise for coming across as a little impatient in previous posts - it's easy to forget how much of a thankless task maintaining a project like this is.

[johnnyreilly]

No worries - I don't want to make too many promises but I'm relatively optimistic that we can fix up the (rather flaky) tests, merge your change and arrange a new publish. The project has rather languished recently - I'm going to try and give it some love. I'm not sure how long it will take to arrange all this but I'm seeing what i can do. All help will be gratefully received!

[johnnyreilly]

Shipped with 0.9

[sky-coding]

@johnnyreilly Way to step up!

[vidartf]

For reference, could you link the PR/commit that fixed it?

[johnnyreilly]

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

[sky-coding]

@johnnyreilly thanks again for resolving this, I ran into an issue with the other typescript loader (which I switched to due to this issue) and without this fix I would've been stuck between a rock and a hard place. It's working great so far for an ng2 library that exports typescript declarations. Thanks!

[johnnyreilly]

Happy to help!