Configuration Inheritance

[weswigham]

Our friends from @angular asked for this feature while they were visiting last week, since they use a lot of configuration files internally.

Proposal

Add a new top-level (alongside compilerOptions, files, includes, and excludes) tsconfig parameter - extends (to steal the term from eslint).

• Its value is a string or an array of strings which are interpreted as rooted or relative paths (so starting with either a drive root or . or ..) from the current tsconfig to other tsconfigs to inherit from - with or without a .json extension, if no extension is provided, we first look for an extensionless file by the name, and failing that, add a .json extension and look for that.
• If we add recommended or built-in configs to inherit from in the future, those will look like a module identifier, rather than a path (ie, "typescript/strict"). For now, non-relative, non-rooted paths will be an error. At present, built-in or shareable configs are not part of this proposal.
• All configs your config inherits from are first parsed and resolved (thereby filling in anything they inherit), and then merged. Configs later in the list override the configuration provided by those earlier in the list. Configuration in the active config can override those provided by an inheriting config. If a circularity is encountered, we report an error.
• If any inherited configs we load have errors, we will report them.
• Top-level members other than compilerOptions are completely overridden by following definitions. compilerOptions at the top level is merged (though its individual keys will still be overridden as though they were top-level keys).
• Relative paths found in the configuration file will be resolved relative to the configuration file they originated in.

Examples

configs/base.json:

{
  "compilerOptions": {
    "allowJs": true,
    "noImplicitAny": true,
    "strictNullChecks": true
  }
}

configs/tests.json:

{
  "compilerOptions": {
    "preserveConstEnums": true,
    "stripComments": false,
    "sourceMaps": true
  },
  "exclude": [
    "../tests/baselines",
    "../tests/scenarios"
  ],
  "include": [
    "../tests/**/*.ts"
  ]
}

tsconfig.json:

{
  "extends": "./configs/base",
  "files": [
    "main.ts",
    "supplemental.ts"
  ]
}

tsconfig.nostrictnull.json:

{
  "extends": "./tsconfig"
  "compilerOptions": {
    "strictNullChecks": false
  }
}

tsconfig.tests.json:

{
  "extends": ["./configs/tests", "./tsconfig"],
  "compilerOptions": {
    "module": "commonjs"
  }
}

tsconfig.tests.browser.json:

{
  "extends": ["./configs/tests", "./tsconfig"],
  "compilerOptions": {
    "module": "amd"
  }
}

@alexeagle @DanielRosenwasser Does this cover your usecases?

[kitsonk]

Not to take anything away from the @angular team 😄, but other projects would benefit from this too. Currently @dojo is managing this via the tooling tasks which overwrite configuration "magically" when doing different targets, but it would be great to just provide this as a .json file that tsc understood inherently.

[weswigham]

@kitsonk We actually started doing the same thing with our debug/release build duality inside the compiler, if you look at our gulpfile. 😆

[alexeagle]

SGTM cc @IgorMinar

I understand about file references being rooted relative to the file requested by -p option, though that is clearly the thorny issue here, as knowledge of resolution is non-local in the tsconfig containing the reference. If tsconfig.json extends ./a.json and subdir/tsconfig.json extends ../a.json there are no correct options for relative paths in a.json?

[weswigham]

@alexeagle Correct. Though, you could still have useful things such as
"exclude": ["node_modules"], which is probably still what you wanted
regardless of where its resolved from. My general recommendation would be
to avoid using paths in inheritable configurations unless you're really
sure you want it. Generally, the config extends member will behave mostly
as Object.assign({}, ...extendedConfigs). Or at least that's the intent.
Rewriting all the paths complicates that a lot... And requires knowledge of
what is a path and what isn't.

[mhegazy]

the config extends member will behave mostly as Object.assign({}, ...extendedConfigs

You could still do this if you say you are merging the "resolved" version of the config files. so you first look at the config file, and make all the file path properties absolute using the containing file location, something we already do today, then merge the result.

[alexeagle]

+1 for resolving the config before merging. Tools will also have an
incredibly hard time with paths in an included file that point to the wrong
place, even if it looks canonical like "node_modules" I don't think the IDE
should be expected to look in parent directories for that.

On Thu, Jul 21, 2016 at 3:53 PM Mohamed Hegazy notifications@github.com
wrote:

the config extends member will behave mostly as Object.assign({},
...extendedConfigs

You could still do this if you say you are merging the "resolved" version
of the config files. so you first look at the config file, and make all the
file path properties absolute using the containing file location, something
we already do today, then merge the result.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#9876 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAC5I98tT3BljBILqW3if1QgQHxljrYxks5qX_hrgaJpZM4JSL8V
.

[weswigham]

@mhegazy We could do that for the top-level options easily, but for things within the compilerOptions hash, it seems like a really dicey proposition. I originally wanted to not resolve anything just because I don't think we can identify every potential path in the compilerOptions hash (specifically, paths which appear in 'object' or 'list' argument kinds). So I thought differing behavior between options would be surprising, making not resolving paths at all the least surprising option.

[mhegazy]

it is very hard to reason about relative paths when consumed in the context of a different file.

we already mark some compiler options as isFilePath and make these absolute relative to the tsconfig.json path. so this would not be too much different here. we just have to resolve them before we do the merge.

[weswigham]

@mhegazy But we don't currently mark members of object compiler options as paths (like the paths option). Also, in the extensibility model pr, I have no way of knowing if an extension's arguments are a path.

[mhegazy]

"paths" is not. it is always relative to baseURL, baseURL however is a file path.

[mhegazy]

for the extensions, this is a hard one. no idea what we can do there. these are opaque objects and we have no visibility in them.

[weswigham]

@mhegazy since paths isn't an issue, I guess we can just resolve all filepaths we see in the config and say that the extensions hash is treated as an opaque object, so you shouldn't rely on inheriting paths in it anyway?

Or maybe I should just not think about extensions, solve this for this, then rebuild the extensions argument structure on top of it? That sounds better, I think.

In any case, I'll update the OP to reflect that we will resolve paths in all path-based options.