Configuration Inheritance

Alex Eagle (@alexeagle)

Our friends from Angular (@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"
  }
}

Alex Eagle (@alexeagle) Daniel Rosenwasser (@DanielRosenwasser) Does this cover your usecases?

Not to take anything away from the Angular (@angular) team 😄, but other projects would benefit from this too. Currently Dojo (@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.

Kitson Kelly (@kitsonk)

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

Igor Minar (@IgorMinar)

SGTM cc Igor Minar (@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?

Alex Eagle (@alexeagle)

Alex Eagle (@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.

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.

+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
.

Mohamed Hegazy (@mhegazy)

Mohamed Hegazy (@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.

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.

Mohamed Hegazy (@mhegazy)

Mohamed Hegazy (@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.

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

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.

Mohamed Hegazy (@mhegazy)

Mohamed Hegazy (@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.

This is certainly more versatile than my suggestion (##9835), yet, perhaps you would like to check with the angular team if the environment based solution (which avoids the relative paths issue) is good enough. I know they source multiple packages from one repo that each have their own tsconfig.json files, so maybe that is their driver. It would be good to add a user story to understand what problems are addressed by this solution.

I'm trying to follow the Angular 2 pattern my repo and figured I was doomed to copy settings everywhere. Multiplackage development it's so common that there is a popular NodeJS tool to support it: https://lernajs.io/

This should be available in the nightly builds starting 9/14/2016

Shall this work with @next? Running 2.1.0-dev.20161004.

In my src/tsconfig.json I keep the global project configuration with es6 modules
In my src/server/tsconfig.json I have following configuration

{
  "extends": "../tsconfig",
  "module": "commonjs"
}

Yet, when I compile my project I still have es6 modules everywhere :/

It isn't going to magically know what files are included and excluded, just based on its location and you would need to invoke the compiler twice.

So in src/tsconfig.json you need to exclude src/server/ and in src/server/tsconfig.json you need to limit to only src/server/ and invoke tsc twice.

Hmm, I'm not sure if I follow correctly. These are my two typings.jsons

/tsconfig.json

{
  "compileOnSave": true,
  "compilerOptions": {
    "target": "es6",
    "module": "es6",
  },
  "include": [
    "./server/**/*.ts",
    "./client/**/*.ts",
    "./client/**/*.tsx",
    "./typings/**/*.ts",
    "./shared/**/*.ts"
  ],
  "exclude": [
    "node_modules",
    "./server/**/*.ts"
  ]
}

and the /server/tsconfig.json

{
  "extends": "../tsconfig.json",
  "module": "commonjs",
  "include": ["./**/*.ts"]
}

Now the server files are not emitted at all.

Where did your extends go in /server/tsconfig.json? How are you invoking the compiler?

Hi, I updated the above example. I simply executed tsc twice in the same destination.

The file that extends a configuration should be a valid configuration file itself, i.e.:

{
  "extends": "../tsconfig.json",
  "compilerOptions": {
      "module": "commonjs"
   }
}

Aleksey-Bykov

Aleksey-Bykov Alright. Done; but I don't think closed issues are normally considered a canonical source of documentation. 😛

Mohamed Hegazy (@mhegazy)

The correct fix here is for TS to add module resolution support for jspm modules. The concerns we had were the relative instability of the framework, the lack of documentation and the runtime configuration structure that is not friendly to static analyzers. I think w need to reasses this for TS2.1; but do not think the approach of auto generating path mapping is sustainable.

Mohamed Hegazy (@mhegazy) Sorry for resurrecting this thread. In spite of your advice, which I still think is correct advice, I heedlessly went ahead with an experiment. I found that analyzing the jspm.confg.js could be used to install correct types and that multiple versions could be supported, but my solution only works with Aurelia, and will fail if they restructure their git repository. However generating paths was surprisingly pleasant, especially since I got to write a node.js app using TypeScript's async/await for the first time. From the experience, I would say that analyzing where to get the declaration files is the difficult part.
Thanks for your time.

In the original proposal it was suggested to allow using arrays as extends values.
But it seems it wasn't implemented (only strings are allowed).

Here's our use case where it's needed to have multiple base config (array in extends).

Given an app written in TS. I have several dependencies installed via bower into vendor_components folder. The app have its own tsconfig.json which is very simple as it's based on other configs:

    "extends": [
      "./vendor_components/ourFramework/tsconfig", 
      "./vendor_components/ourModule/tsconfig"
    ],
    "include": [
        "src/**/*.ts",
        "src/**/.*.ts",
        "vendor_components/ourFramework/src/**/*.ts",
        "vendor_components/ourFramework/src/**/.*.ts",
        "vendor_components/ourModule/src/**/*.ts",
        "vendor_components/ourModule/src/**/.*.ts"
    ]

The config "./vendor_components/ourFramework/tsconfig" is major, it describes all compilerOptions. But ourModule's config is also needed as it contains paths,
like:

"lib/*": [ "src/lib/*" ],

So it's ok if a lib/fw in vendor_components contains its own tsconfig. If the app want include that lib/fw sources it should use that tsconfig as well. But currently it can use only one. Other's config have to replicated in app's tsconfig.

Navigation Menu

Repository navigation

Configuration Inheritance #9876

Proposal

Examples

17 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Configuration Inheritance #9876

Description

Proposal

Examples

Activity

kitsonk commented on Jul 21, 2016

weswigham commented on Jul 21, 2016

alexeagle commented on Jul 21, 2016

weswigham commented on Jul 21, 2016

mhegazy commented on Jul 21, 2016

alexeagle commented on Jul 21, 2016

weswigham commented on Jul 21, 2016

mhegazy commented on Jul 21, 2016

weswigham commented on Jul 21, 2016

mhegazy commented on Jul 21, 2016

mhegazy commented on Jul 21, 2016

weswigham commented on Jul 21, 2016

clavecoder commented on Jul 22, 2016

17 remaining items

mhegazy commented on Sep 13, 2016

tomitrescak commented on Oct 4, 2016

kitsonk commented on Oct 4, 2016

tomitrescak commented on Oct 4, 2016

kitsonk commented on Oct 4, 2016

tomitrescak commented on Oct 4, 2016

mhegazy commented on Oct 4, 2016

weswigham commented on Oct 15, 2016

aluanhaddad commented on Oct 16, 2016

evil-shrike commented on Mar 24, 2017

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions