Config files don't work in arbitrary places

[loilo]

Related to #607.

If the configFile option is set to a path and points to a tsconfig.json outside the respective entry point's parent directory chain, the config file will be found and used, but the webpack process will throw errors. (Usually that's a TS18003: No inputs were found in config file).

I assume this is TypeScript not being able to handle the "unusual" location of the tsconfig.json.

I'll investigate this and see what we can do about this.

[loilo]

Okay, I get what's going on.

---

Setup

First, let's assume we've got a project like this:

/var/www/project/
├── config/
│   └── tsconfig.json
├── src/
│   └── main.ts
└── webpack.config.js

with the following webpack config:

module.exports = {
  entry: './src/main.ts',
  output: {
    filename: 'bundle.js'
  },
  module: {
    rules: [
      {
        test: /\.ts$/,
        use: [
          {
            loader: 'ts-loader',
            options: {
              configFile: '../config/tsconfig.json'
            }
          }
        ]
      }
    ]
  }
}

---

What's the problem?

Running webpack, ts-loader is, as it should, calling the TypeScript compiler via the parseJsonConfigFileContent() method. That method is provided a basePath as the third argument.

• relevant ts-loader source
• relevant TypeScript source

ts-loader uses the path to the directory holding the tsconfig.json as the base path. In our example structure, this would be /var/www/project/config.

However, TypeScript will not accept source files outside this base path (which the main.ts in /var/www/project/src clearly is) and throw errors during compilation. Unfortunately, the errors don't make it too clear what's happening:

The entry point file main.ts is not accepted, there are no other files provided via tsconfig's include or files options.

→ There are no files to compile.

→ The build fails.

---

So what can we do about this?

I'm personally all-in on just using TypeScript's built-in possibilities, or respectively, making them work like one would expect them to:

The TypeScript compilerOptions have support for the rootDir property. It accepts an absolute path or a path relative to the tsconfig.json that will determine the project's base path.

Unfortunately, settings this option in our example tsconfig will not override the basePath we provide to the parseJsonConfigFileContent().

---

This is my suggestion:

Instead of just providing the parent folder of the tsconfig as the base path, let's look into the config (which is already parsed and available anyway) let's use the rootDir option:

• If it's not present, the basePath is determined just like it currently is.
• If it's an absolute path, that will be our basePath argument.
• If it's a relative path, it will be resolved relative to the tsconfig's folder — just like TypeScript does it.

---

Disclaimer:

• I've already tested this behaviour locally, it works like a charm. 😉

• Technically, this is a breaking change in that it's changing currently working behaviour. However — just as Add configFile option #607 introduced such a change — the behaviour broken is a very weird one:

  It breaks builds that provide a rootDir option in their tsconfig, even though it doesn't currently do anything. After this change, the rootDir suddenly would work, and if it's provided some weird path, it may break builds.

  It should also be considered that this breaking change is, on the other hand, also a fix to the current behaviour. We're claiming that the user can set the path to the tsconfig.json, which is, regarding this issue, only partially true.

  The two alternatives to introducing this BC are:

  • Find another solution, probably with a new ts-loader option (which I consider suboptimal since it imho adds unnecessary cognitive load).
  • Don't allow paths to tsconfig files outside the respective entry point file's parent chains at all.

  I personally think that the described BC is justifiable as it neither includes any logical break with current behaviour nor does it break any hacks that people may have used (since the rootDir option currently really has no effect).

[johnnyreilly]

I agree with you I think - what you're saying makes sense. Do it!