Working with tslint-loader

[morriq]

Hello, since I'm using tslint-loader I have issue with tsconfig-paths.

My problem is that tslint-loader try to load tslint using var Lint = require('tslint'); https://github.com/wbuchwalter/tslint-loader/blob/4d166651d916a0c43dd5a11099d6ff532350e27b/index.js#L8

but same file exists in my project so while tslint-loader try to load tslint from node_modules then it's receiving tslint from my project.

Would somebody help me please?

[Jontem]

Sorry for the late response. Is this still a problem? Maybe we could implement an option for specifying excluded modules names that should not be resolved with tsconfig-paths

[mihkeleidast]

As far as I know, this is still a problem. A workaround I have used is setting "baseUrl": "./src", in my tsconfig, that way it does not try to resolve files in root.

[stenin-nikita]

In my opinion, this implementation is more correct and also solves the problem above

  Module._resolveFilename = function(request: string, _parent: any): string {
    try {
      // tslint:disable-next-line:no-invalid-this
      return originalResolveFilename.apply(this, arguments);
    } catch (err) {
      const found = matchPath(request);
      if (found) {
        const modifiedArguments = [found, ...[].slice.call(arguments, 1)]; // Passes all arguments. Even those that is not specified above.
        // tslint:disable-next-line:no-invalid-this
        return originalResolveFilename.apply(this, modifiedArguments);
      }

      throw err;
    }
  };

[jonaskello]

Just to clarify let me see if I understand how to re-create the problem:

• Use tslint-loader with webpack.
• Have a tslint.json file in the root of the project.
• Start webpack somehow with tsconfig-paths registered.

Is that correct?

Also, iIf someone would like to provide a repo which reproduces the problem that would also save us some time to try and re-create it.

[stenin-nikita]

I recreated the problem in the sandbox. You need to download the project and run npm install and npm start. https://codesandbox.io/s/7klz2y4v30

[stenin-nikita]

I think my solution will not cause performance problems. It may be worth checking the type of error. For example:

    try {
      // tslint:disable-next-line:no-invalid-this
      return originalResolveFilename.apply(this, arguments);
    } catch (err) {
      if (err.code === 'MODULE_NOT_FOUND') {
        const found = matchPath(request);
        if (found) {
          const modifiedArguments = [found, ...[].slice.call(arguments, 1)]; // Passes all arguments. Even those that is not specified above.
          // tslint:disable-next-line:no-invalid-this
          return originalResolveFilename.apply(this, modifiedArguments);
        }
      }
      throw err;
    }

[Athorcis]

what about adding an option disabled by default to enabled this behavior ?