Can't import plain d.ts files when transpileOnly=true

[ronzeidman]

This is actually the exact same issue as I have with awesome-typescript-loader: s-panferov/awesome-typescript-loader#225:

I have a shared module for shared interfaces between my server and my client. It contains several d.ts files with interfaces I share between my server and the UI. When I use ts-loader everything works as expected, when I use this ts-loader with transpileOnly=true I get:

ERROR in ./src/component.ts
Module not found: Error: Cannot resolve module 'shared/data' in ...src/component
 @ ./src/component.ts 12:26-73

The shared/data should be shared/data.d.ts but it doen't find it. If I add the d.ts explicitly I get this error:

ERROR in ./~/shared/data.d.ts
Module build failed: Error: Debug Failure. False expression: Output generation failed
    at Object.assert (node_modules\typescript\lib\typescript.js:2099:23)
    at Object.transpileModule (node_modules\typescript\lib\typescript.js:53173:18)
    at Object.loader (node_modules\ts-loader\index.js:421:49)
 @ ./src/component.ts 12:31-83

configuration:

'ts-loader?' + JSON.stringify({
                        transpileOnly: true,
                        configFileName: 'tsconfig.webpack.json'
                    })

config file:

{
    "compilerOptions": {
        "isolatedModules": true,
        "emitDecoratorMetadata": true,
        "experimentalDecorators": true,
        "module": "es6",
        "moduleResolution": "node",
        "noImplicitAny": false,
        "sourceMap": true,
        "target": "es5"
   },
   "files": ["src/component"]
}

Not critical workaround is to just change the files to ts files and transpile them to empty js files.

[stefan-leye]

Is there any solution for this?

[digimax]

Wow, is this for real? yes it is. holy crap. totally wasted 4 hours on that. this is only clue that comes up on Google after 4 hours of banging on it with a hammer.

[stefan-leye]

Yeah, actually it is real. And I don't know a proper workaround. How do projects with external libraries like angular work in transpileOnly mode? I mean it is obviously not feasible to convert their typings into normal .ts files.

[jbrantly]

How are you importing the module?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

Closing as stale. Please reopen if you'd like to work on this further.

[Timmmm]

ARRRGH! How do I fix this? All I've done is this:

1. Create a default vue app using Typescript.

2. Generate protobuf Typescript files.

3. Try to import them like this:

   import {Memory} from './foo_pb';

The file ./foo_pb.d.ts exists god damn it but it still says it cannot resolve it.

Sorry for being a bit pissed off but this is surely a basic thing that should work, and I've been trying to solve it all day.

Renaming to foo_pb.ts does not work because then it gives a load of errors about the functions not having definitions (fair enough - they are in memory.js).

Please reopen this.

[johnnyreilly]

Reopened. I'm not working on this, but if you'd like to have a crack at it and raise a prospective pr I'd be happy to support you

[Timmmm]

Actually I think I was looking in the wrong place for the problem. I was using some files generated by protoc, and due to a stupid design it was possible to give it "unsupported" options, and it would silently ignore them and only generate some files. It should have generated foo_pb.d.ts and foo_pb.js, but it wasn't generating the latter file. With that file present the import works (and I do have transpileOnly=true).

So maybe it was working as intended all along. Sorry!!

[bodinsamuel]

Hi everyone,
do we have any idea how to fix this?
renaming to .ts works but feels wrong :(

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[bodinsamuel]

still relevant 😢

[johnnyreilly]

I'm afraid I can't spend any time looking into this directly, but if you'd like to I'd appreciate it and I'll help when I can

[sanex3339]

Same

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

Closing as stale. Please reopen if you'd like to work on this further.

[joebnb]

still relevant

[LvChengbin]

I encountered the same issue.
It's because there is another loader in my webpack config file and it calls ts-loader without setting transpileOnly to true.

[artyomtrityak]

Same issue, any advice?

[eas604]

I have found a fairly clean workaround to this problem (specifically, for getting transpileOnly to work with .d.ts files under fork-ts-checker-webpack-plugin). Any interface that you import from a .d.ts file, use import type rather than plain import. The plugin will then parse the definition file and correctly type check against it. No more import errors!

@joebnb, @LvChengbin, and @artyomtrityak, perhaps this strategy will work for you.

Special thanks to @dhoulb for getting me on the right track in this comment.

[xxxgitone]

Removing the emitDecoratorMetadata works, but I don't know why.😢

[pahor167]

I have found a fairly clean workaround to this problem (specifically, for getting transpileOnly to work with .d.ts files under fork-ts-checker-webpack-plugin). Any interface that you import from a .d.ts file, use import type rather than plain import. The plugin will then parse the definition file and correctly type check against it. No more import errors!

@joebnb, @LvChengbin, and @artyomtrityak, perhaps this strategy will work for you.

Special thanks to @dhoulb for getting me on the right track in this comment.

Unfortunately this does not work if d.ts file includes also something else (eg. enums) than just interfaces.

[eas604]

You're right about that. You ought to be able to import type for interfaces, and do a separate import for enums and such. If you're hoping instead to import entire files, you may need to move enums to separate files. I would normally be averse to architecting around a local development plugin, but the velocity savings are huge and worth it in my opinion.