ts-loader breaking when it's used with TS Path mappings based module resolution

[bruk1977]

I'm using Path Mapping based Module resolution feature of TypeScript 2.0 and ts-loader failing with 'can not resolve module' error.

To repro the issue, please follow the following steps:

• clone my sample
• npm install
• in tsconfig.json, change the baseUrl to the local location of the clone.
• webpack

You will get the following error:

ERROR in ./src/utility/utility.ts
Module not found: Error: Cannot resolve module 'stringExtensions' in d:\tsLoaderFailingWithModuleNodeResolution\sample\src\utility

It's working fine when I'm running the following command:
tsc -p tsconfig.json

[DanielRosenwasser]

@bruk1977, is the expected behavior to load these from resolve, would resolve get set by the path mapping options in tsconfig.json, or would they be considered independent?

Is there a convention for this sort of thing @jbrantly?

[bruk1977]

@DanielRosenwasser, it would be so nice if resolve get populated from tsconfig.json automatically. That way no need to update 2 configs (tsconfig.json & webpack.config.js) at build time.

[bruk1977]

@jbrantly, @DanielRosenwasser any recommendation? Thanks!

[DanielRosenwasser]

Edit: Don't do this, it won't work. See below.

Until this is fixed, I think you can create a series of ambient module declarations in a file called pathMapper.d.ts that re-exports from the paths you actually need to import from.

declare module "foo" {
    import m = require("../my_dependencies/foo");
    export = m;
}

[bruk1977]

Thanks for the suggestion @DanielRosenwasser I couldn't make it working. Can you please update my sample and show me how ambient module help? Thanks a lot again!

[DanielRosenwasser]

Scratch that last suggestion. I've found a better fix.

Fix up your resolve property to look something like this:

  resolve: {
    // Add `.ts` and `.tsx` as a resolvable extension.
    extensions: ['', '.webpack.js', '.web.js', '.ts', '.tsx', '.js'],

    // Configure path resolution strategy
    modulesDirectories: [
      ".",
      "src/extension/",
      "src/utility/"
    ]
  },

That should keep it in sync with the path mappings in your tsconfig.json which looked like:

    "paths": {
      "*": [
        "*",
        "src/extension/*",
        "src/utility/*"
      ]
    }

Let me know how that works.

[bruk1977]

Thanks a lot @DanielRosenwasser -- it works charmingly with your first config.

resolve: { // Add.tsand.tsxas a resolvable extension. extensions: ['', '.webpack.js', '.web.js', '.ts', '.tsx', '.js'], modulesDirectories: [ ".", "src/extension/", "src/utility/" ] }

It doesn't work if I use the same mapping I've in tsconfig.

resolve: { // Add.tsand.tsxas a resolvable extension. extensions: ['', '.webpack.js', '.web.js', '.ts', '.tsx', '.js'], modulesDirectories: [ ".", "src/extension/*", "src/utility/*" ] },

On the other hand, Typescript compiler working with the second way of mapping... it required '' at the end. Is there any way 'moduleDirectories' working with '' at the end? The reason I can't break TS compiler is I've a another build pipeline that required to build individual files using TSC.

[adamreisnz]

+1, would be nice if ts-loader would be able to automatically parse the paths/baseUrl properties from tsconfig.js. Took me a while to figure out that the problem was that I wasn't including the paths in resolve, and not with my tsconfig.js configuration.

[tp]

Extending the modulesDirectory setting should work for simple mappings, but what about more complex mappings where * is used in the middle? Something that TS allows, but I haven't yet been able to re-create in webpack.

"paths": {
      "*": [
        "*",
        "components/*/src"
      ]
}

If this is not possible, I would have to add a package.json with a typings field of "src/index.ts" to every component folder, but would rather prefer to have this working without dummy files.

[TheLarkInn]

@tp @DanielRosenwasser @johnnyreilly @jbrantly

I have whipped up an isolated webpack Resolver plugin (thanks to @s-panferov) that may apply the module resolution strategy over to webpack correctly with support for fallbacks etc.

@bruk1977 @adambuczynski would you please try this out? If you don't use ts-node you can es5 it and implement. https://github.com/angular/angular-cli/blob/webpack/addon/ng2/utilities/ts-path-mappings-webpack-plugin.ts

Usage is found here:
s-panferov/awesome-typescript-loader#156 (comment)

[adamreisnz]

@TheLarkInn I don't think having to add some paths to the resolve array weighs up against having to add an additional plugin/dependency.

For me, the following now works and is quite simple to implement/manage once you know how to:

tsconfig.json example (simplified):

{
  "compilerOptions": {
    "target": "es5",
    "moduleResolution": "node",
    "baseUrl": ".",
    "paths": {
      "*": [
        "app/components/*",
        "app/*"
      ]
    }
  }
}

And corresponding webpack config:

  //Resolve rules
  resolve: {
    extensions: [
      '', '.js', '.ts', '.scss'
    ],
    root: [
      path.join(ROOT, 'app'),
      path.join(ROOT, 'app/components'),
      path.join(ROOT, 'node_modules')
    ]
  },

But as I said, it would be great if webpack could detect this on it's own rather than having to do it by hand or with an extra plugin.

[TheLarkInn]

How would handle something like this:

paths": {
      "@angular2-material/core/*": [
        "./core/*",
        "../core/*"
      ],
      "@angular2-material/*": [
        "./components/*",
        "../components/*"
      ]
    }

[adamreisnz]

@TheLarkInn I don't know, I haven't had a use case for that. For now, it's fulfilling all my requirements and needs :)

[bruk1977]

@TheLarkInn Love trying but when I'm trying to install wepback@2.1 or webpack@next I'm getting the below error.. .any idea?

silly fetchPackageMetaData Error: No compatible version found: webpack@2.1
26 silly fetchPackageMetaData Valid install targets:
26 silly fetchPackageMetaData 2.1.0-beta.15, 2.1.0-beta.14, 2.1.0-beta.13, 2.1.0-beta.12, 2.1.0-beta.11, 2.1.0-beta.10, 2.1.0-beta.9, 2.1.0-beta.8, 2.1.0-beta.7, 2.1.0-beta.6, 2.1.0-beta.5, 2.1.0-beta.4, 2.1.0-beta.3, 2.1.0-beta.2, 2.1.0-beta.1, 2.1.0-beta.0, 2.0.7-beta, 2.0.6-beta, 2.0.5-beta, 2.0.4-beta, 2.0.2-beta, 2.0.1-beta, 2.0.0-beta, 1.13.1, 1.13.0, 1.12.15, 1.12.14, 1.12.13, 1.12.12, 1.12.11, 1.12.10, 1.12.9, 1.12.8, 1.12.7, 1.12.6, 1.12.5, 1.12.4, 1.12.3, 1.12.2, 1.12.1, 1.12.0, 1.11.0, 1.10.5, 1.10.4, 1.10.3, 1.10.2, 1.10.1, 1.10.0, 1.9.13, 1.9.12, 1.9.11, 1.9.10, 1.9.9, 1.9.8, 1.9.7, 1.9.6, 1.9.5, 1.9.4, 1.9.3, 1.9.2, 1.9.1, 1.9.0, 1.8.11, 1.8.10, 1.8.9, 1.8.8, 1.8.7, 1.8.6, 1.8.5, 1.8.4, 1.8.3, 1.8.2, 1.8.1, 1.8.0, 1.7.3, 1.7.2, 1.7.1, 1.7.0, 1.6.0, 1.5.3, 1.5.2, 1.5.1, 1.5.0, 1.4.15, 1.4.14, 1.4.13, 1.4.12, 1.4.11, 1.4.10, 1.4.9, 1.4.8, 1.4.7, 1.4.6, 1.4.5, 1.4.4, 1.4.3, 1.4.2, 1.4.1-beta1, 1.4.0-beta9, 1.4.0-beta8, 1.4.0-beta7, 1.4.0-beta6, 1.4.0-beta5, 1.4.0-beta4, 1.4.0-beta3, 1.4.0-beta2, 1.4.0-beta10, 1.4.0-beta1, 1.3.7, 1.3.6, 1.3.5, 1.3.4, 1.3.3-beta2, 1.3.3-beta1, 1.3.2-beta9, 1.3.2-beta8, 1.3.2-beta7, 1.3.2-beta6, 1.3.2-beta5, 1.3.2-beta4, 1.3.2-beta3, 1.3.2-beta2, 1.3.2-beta1, 1.3.1-beta9, 1.3.1-beta8, 1.3.1-beta7, 1.3.1-beta6, 1.3.1-beta5, 1.3.1-beta4, 1.3.1-beta3, 1.3.1-beta2, 1.3.1-beta1, 1.3.0-beta9, 1.3.0-beta8, 1.3.0-beta7, 1.3.0-beta6, 1.3.0-beta5, 1.3.0-beta4, 1.3.0-beta3, 1.3.0-beta2, 1.3.0-beta1, 1.2.0-beta6, 1.2.0-beta5, 1.2.0-beta4, 1.2.0-beta2, 1.2.0-beta1, 1.1.11, 1.1.10, 1.1.9, 1.1.8, 1.1.7, 1.1.6, 1.1.5, 1.1.4, 1.1.3, 1.1.2, 1.1.1, 1.1.0, 1.1.0-beta9, 1.1.0-beta8, 1.1.0-beta7, 1.1.0-beta6, 1.1.0-beta5, 1.1.0-beta4, 1.1.0-beta3, 1.1.0-beta2, 1.1.0-beta12, 1.1.0-beta10, 1.1.0-beta1, 1.0.5, 1.0.4, 1.0.3, 1.0.1, 1.0.0, 1.0.0-rc9, 1.0.0-rc8, 1.0.0-rc7, 1.0.0-rc5, 1.0.0-rc4, 1.0.0-rc3, 1.0.0-rc2, 1.0.0-rc12, 1.0.0-rc11, 1.0.0-rc1, 1.0.0-beta9, 1.0.0-beta8, 1.0.0-beta7, 1.0.0-beta6, 1.0.0-beta5, 1.0.0-beta4, 1.0.0-beta3, 1.0.0-beta2, 1.0.0-beta1, 0.11.18, 0.11.17, 0.11.16, 0.11.15, 0.11.14, 0.11.13, 0.11.12, 0.11.11, 0.11.10, 0.11.9, 0.11.8, 0.11.7, 0.11.6, 0.11.5, 0.11.4, 0.11.3, 0.11.2, 0.11.1, 0.11.0, 0.11.0-beta9, 0.11.0-beta8, 0.11.0-beta7, 0.11.0-beta6, 0.11.0-beta5, 0.11.0-beta4, 0.11.0-beta3, 0.11.0-beta29, 0.11.0-beta28, 0.11.0-beta27, 0.11.0-beta26, 0.11.0-beta25, 0.11.0-beta24, 0.11.0-beta23, 0.11.0-beta22, 0.11.0-beta21, 0.11.0-beta20, 0.11.0-beta2, 0.11.0-beta19, 0.11.0-beta18, 0.11.0-beta17, 0.11.0-beta16, 0.11.0-beta15, 0.11.0-beta14, 0.11.0-beta13, 0.11.0-beta12, 0.11.0-beta11, 0.11.0-beta10, 0.11.0-beta1, 0.10.0, 0.10.0-beta9, 0.10.0-beta8, 0.10.0-beta7, 0.10.0-beta6, 0.10.0-beta5, 0.10.0-beta3, 0.10.0-beta25, 0.10.0-beta24, 0.10.0-beta23, 0.10.0-beta22, 0.10.0-beta21, 0.10.0-beta20, 0.10.0-beta2, 0.10.0-beta19, 0.10.0-beta18, 0.10.0-beta17, 0.10.0-beta16, 0.10.0-beta15, 0.10.0-beta14, 0.10.0-beta13, 0.10.0-beta12, 0.10.0-beta11, 0.10.0-beta10, 0.9.3, 0.9.2, 0.9.1, 0.9.0, 0.9.0-beta9, 0.9.0-beta8, 0.9.0-beta7, 0.9.0-beta6, 0.9.0-beta5, 0.9.0-beta4, 0.9.0-beta38, 0.9.0-beta37, 0.9.0-beta36, 0.9.0-beta35, 0.9.0-beta34, 0.9.0-beta33, 0.9.0-beta32, 0.9.0-beta31, 0.9.0-beta30, 0.9.0-beta29, 0.9.0-beta28, 0.9.0-beta27, 0.9.0-beta26, 0.9.0-beta25, 0.9.0-beta24, 0.9.0-beta23, 0.9.0-beta22, 0.9.0-beta21, 0.9.0-beta20, 0.9.0-beta2, 0.9.0-beta19, 0.9.0-beta18, 0.9.0-beta17, 0.9.0-beta16, 0.9.0-beta15, 0.9.0-beta14, 0.9.0-beta13, 0.9.0-beta12, 0.9.0-beta11, 0.9.0-beta10, 0.9.0-beta1, 0.8.3, 0.8.2, 0.8.0, 0.8.0-beta4, 0.8.0-beta3, 0.8.0-beta2, 0.8.0-beta1, 0.7.17, 0.7.16, 0.7.15, 0.7.14, 0.7.13, 0.7.12, 0.7.11, 0.7.9, 0.7.8, 0.7.7, 0.7.6, 0.7.5, 0.7.4, 0.7.3, 0.7.2, 0.7.1, 0.7.0, 0.7.0-beta8, 0.7.0-beta7, 0.7.0-beta6, 0.7.0-beta5, 0.7.0-beta4, 0.7.0-beta3, 0.7.0-beta2, 0.7.0-beta, 0.6.2, 0.6.1, 0.6.0, 0.5.10, 0.5.8, 0.5.7, 0.5.6, 0.5.5, 0.5.4, 0.5.3, 0.5.2, 0.5.1, 0.5.0, 0.4.25, 0.4.24, 0.4.23, 0.4.21, 0.4.20, 0.4.19, 0.4.18, 0.4.17, 0.4.16, 0.4.15, 0.4.14, 0.4.13, 0.4.12, 0.4.11, 0.4.10, 0.4.9, 0.4.8, 0.4.7, 0.4.6, 0.4.5, 0.4.4, 0.4.3, 0.4.2, 0.4.1, 0.4.0, 0.3.20, 0.3.19, 0.3.18, 0.3.17, 0.3.16, 0.3.15, 0.3.14, 0.3.13, 0.3.12, 0.3.11, 0.3.10, 0.3.9, 0.3.8, 0.3.7, 0.3.6, 0.3.4, 0.3.3, 0.3.2, 0.3.1, 0.3.0, 0.2.8, 0.2.7, 0.2.6, 0.2.4, 0.2.3, 0.2.2, 0.2.1, 0.2.0, 0.1.6, 0.1.5, 0.1.4, 0.1.3, 0.1.2, 0.1.1, 0.1.0

[TheLarkInn]

webpack@2.1.0-beta.15 give that a try

[bruk1977]

Thanks @TheLarkInn -- 2.1.0-beta.15 install working. However, I'm getting the below error. I updated my sample and you can repro. Is there a bug in the plugin or do I miss anything?

Error:
RangeError: Maximum call stack size exceeded
at Array.filter (native)
at D:\temp\sample\node_modules\tapable\lib\Tapable.js:204:18
at D:\temp\sample\node_modules\enhanced-resolve\lib\UnsafeCachePlugin.js:37:19
at loggingCallbackWrapper (D:\temp\sample\node_modules\enhanced-resolve\lib\createInnerCallback.js:31:19)
at innerCallback (D:\temp\sample\node_modules\enhanced-resolve\lib\Resolver.js:119:19)
at loggingCallbackWrapper (D:\temp\sample\node_modules\enhanced-resolve\lib\createInnerCallback.js:31:19)
at D:\temp\sample\node_modules\tapable\lib\Tapable.js:210:15
at innerCallback (D:\temp\sample\node_modules\enhanced-resolve\lib\Resolver.js:119:19)
at loggingCallbackWrapper (D:\temp\sample\node_modules\enhanced-resolve\lib\createInnerCallback.js:31:19)
at D:\temp\sample\node_modules\tapable\lib\Tapable.js:210:15
at D:\temp\sample\node_modules\enhanced-resolve\lib\DescriptionFilePlugin.js:41:20
at loggingCallbackWrapper (D:\temp\sample\node_modules\enhanced-resolve\lib\createInnerCallback.js:31:19)
at innerCallback (D:\temp\sample\node_modules\enhanced-resolve\lib\Resolver.js:119:19)
at loggingCallbackWrapper (D:\temp\sample\node_modules\enhanced-resolve\lib\createInnerCallback.js:31:19)
at D:\temp\sample\node_modules\tapable\lib\Tapable.js:210:15
at D:\temp\sample\node_modules\awesome-typescript-loader\src\paths-plugin.ts:147:36
at loggingCallbackWrapper (D:\temp\sample\node_modules\enhanced-resolve\lib\createInnerCallback.js:31:19)
at Tapable.doResolve (D:\temp\sample\node_modules\enhanced-resolve\lib\Resolver.js:93:11)
at Tapable. (D:\temp\sample\node_modules\awesome-typescript-loader\src\paths-plugin.ts:140:29)
at Tapable.applyPluginsParallelBailResult1 (D:\temp\sample\node_modules\tapable\lib\Tapable.js:215:14)
at beforeInnerCallback (D:\temp\sample\node_modules\enhanced-resolve\lib\Resolver.js:110:19)
at loggingCallbackWrapper (D:\temp\sample\node_modules\enhanced-resolve\lib\createInnerCallback.js:31:19)
at Tapable.applyPluginsAsyncSeriesBailResult1 (D:\temp\sample\node_modules\tapable\lib\Tapable.js:108:46)
at Tapable.doResolve (D:\temp\sample\node_modules\enhanced-resolve\lib\Resolver.js:98:11)
at D:\temp\sample\node_modules\enhanced-resolve\lib\DescriptionFilePlugin.js:40:13
at D:\temp\sample\node_modules\enhanced-resolve\lib\DescriptionFileUtils.js:49:12
at D:\temp\sample\node_modules\enhanced-resolve\lib\forEachBail.js:29:14
at onJson (D:\temp\sample\node_modules\enhanced-resolve\lib\DescriptionFileUtils.js:40:5)
at D:\temp\sample\node_modules\enhanced-resolve\lib\DescriptionFileUtils.js:18:6
at Storage.provide (D:\temp\sample\node_modules\enhanced-resolve\lib\CachedInputFileSystem.js:53:20)

[Jameskmonger]

Is it possible for ts-loader to get my information from paths in tsconfig.json and set them up as resolve.alias entries?

At the moment I have to duplicate my config between tsconfig.json and webpack.config.js, like so:

    "paths": {
      "~data/*": [ "Scripts/data/*" ] 
    } 

    resolve: {
        alias: {
            "~data": path.resolve(__dirname, "./Scripts/data/")
        }
    },

[Merott]

The Angular compiler solves this with a plugin.

It's possible to use the plugin in any non-Angular webpack configuration. Just have to install @ngtools/webpack, then add this to the webpack plugins list:

{
  apply(compiler) {
    compiler.plugin('normal-module-factory', nmf => {
      const PathsPlugin = require('@ngtools/webpack').PathsPlugin;
      
      compiler.resolvers.normal.apply(new PathsPlugin({
        nmf,
        tsConfigPath: path.resolve(__dirname, 'tsconfig.json'),
      }));
    });
  }
}

[johnnyreilly]

@Merott - thanks for sharing! I don't suppose you'd fancy submitting a docs PR to aid discoverability of this solution? Also, I'm slightly curious about your usage example above.

I'd anticipated usage that looked something like this in your webpack.config.js:

const PathsPlugin = require('@ngtools/webpack').PathsPlugin;

// .... 

new TsConfigPathsPlugin({
   tsconfig: path.resolve(__dirname, 'tsconfig.json'),
})

// .... 

But this is different to what you have; I'm guessing there's a reason your setup is different but I wonder if you could elaborate?

[Merott]

@johnnyreilly - the usage has to do with the constructor API for PathsPlugin in @ngtools/webpack.

The constructor expects an options object, with the tsConfigPath and nmf as minimum. That's why I've had to wrap it with my own inline plugin definition. I guess we could do this too:

const PathsPlugin = require('@ngtools/webpack').PathsPlugin;

function TsConfigPathsPlugin(tsConfigPath) {
  this._tsConfigPath = tsConfigPath;
}

TsConfigPathsPlugin.prototype.apply = function (compiler) {
  compiler.plugin('normal-module-factory', normalModuleFactory => {
    compiler.resolvers.normal.apply(new PathsPlugin({
      nmf: normalModuleFactory,
      tsConfigPath: this._tsConfigPath,
    }));
  });
};

module.exports = {
  // ... webpack configuration
  plugins: [
    new TsConfigPathsPlugin(path.resolve(__dirname, 'tsconfig.json')),
  ]
}

That's the best I can come up with, though I'm not a webpack expert, so tell me if there's a better way or an API that can help.

As this seems a little bit tedious, I'm not sure if it would be good as an official solution to appear in the docs.

[johnnyreilly]

Thanks for the clarification. Might be good to lift the existing plugin and create a standalone one. I think that's what awesome-typescript-loader has done. I wonder if we could just use that as is? That'd make things easier.

[johnnyreilly]

@Merott,

I don't suppose you could try something for me could you? Would you be able to add awesome-typescript-loader as a dev dependency of your project and follow the instructions here for using the Path's plugin. I'm guessing your code would look something like this:

const { TsConfigPathsPlugin } = require('awesome-typescript-loader');

resolve: {
    plugins: [
        new TsConfigPathsPlugin( ... )
    ]
}

If that works I wonder if they'd be up for publishing this as a standalone package that could be used by ts-loader and awesome-typescript-loader alike?

[zuzusik]

@johnnyreilly I can confirm that the solution from the post above works great for me:

I have the following code:

webpack.config.js:

const {TsConfigPathsPlugin} = require('awesome-typescript-loader');

resolve: {
  plugins: [
    new TsConfigPathsPlugin()
  ]
}

tsconfig.json:

"baseUrl": ".",
"paths": {
  "shared-services/*": ["./app/shared/services/*"]
}

[johnnyreilly]

That's awesome @zuzusik! Would you be able to share a minimal that demonstrates this? I'd like to document this usage and also add a test to our testpack that uses the paths plugin.

With a minimal repo I could probably do that. I don't use this functionality myself and so I don't have any example code of my own I could use.

[jonaskello]

You could also use the tsconfig-paths-webpack-plugin package together with ts-loader in order to resolve baseUrl and paths from tsconfig.json. This is now mentioned here in the readme so I guess this can be closed?

[johnnyreilly]

Yeah - works for me. I still should really get round to creating an execution test for our test pack that covers using ts-loader with another plugin providing the path functionality. Haven't yet though. If anyone feels motivated to provide that I'd appreciate it.

I'll close this though.

[cime]

tsconfig-paths-webpack-plugin is not working with Webpack 4 yet...
A simple temporary solution based on @Jameskmonger post above:

const tsConfig = require("./tsconfig.json");
const alias = {};
for (let key of Object.keys(tsConfig.compilerOptions.paths)) {
    alias[key.replace(/\/\*$/, "")] = path.resolve(__dirname, tsConfig.compilerOptions.paths[key][0].replace(/[\/]\*$/, ""));
}

....

resolve: {
    ....
    alias: alias
}

[jonaskello]

@cime Could you please report the problems you are experiencing with webpack 4 and tsconfig-paths-webpack-plugin in this issue.

[duffman]

Maybe this tool I made for resolving paths might be handy (to someone)?
https://www.npmjs.com/package/tspath