Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Configuration Inheritance #9941

Merged
merged 3 commits into from
Sep 13, 2016
Merged

Configuration Inheritance #9941

merged 3 commits into from
Sep 13, 2016

Conversation

weswigham
Copy link
Member

Fixes #9876

Implements with the semantics proposed in that issue.

@weswigham weswigham mentioned this pull request Jul 26, 2016
Closed
@weswigham
Copy link
Member Author

weswigham commented Jul 30, 2016 •
edited
Loading

Since @alexeagle was concerned about editor support, I've manually tested this change within vscode - as expected, there are no changes required to vscode to make it work, you just drop in the new tsserver. 😉

Once this is merged and we do an LKG (so our lib folder has the feature), I'll update all of our own configs to make use of this feature - it'll seriously reduce the duplication in our options (and likely simplify our Gulpfile a lot!)

@clavecoder
Copy link

Can @basarat test this on atom-typescript?

@weswigham
Copy link
Member Author

also, cc: @paulvanbrenk to review this and check that VS should also be fine with this change.

sandersn
sandersn reviewed Aug 2, 2016
View reviewed changes
src/compiler/core.ts
@@ -171,6 +171,20 @@ namespace ts {
return result;
}

export function mapObject<T, U>(object: Map<T>, f: (key: string, x: T) => [string, U]): Map<U> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

jsdoc would be nice here, specifically calling out what happens when keys are mapped to the same key (looks like last one wins and earlier ones are discarded)

@weswigham
Copy link
Member Author

@mhegazy Is there a reason multiple inheritance was undesirable? IMO, It was useful for mixing in a standard set of debug options into another config hierarchy to avoid duplication.

@mhegazy
Copy link
Contributor

mhegazy commented Aug 30, 2016

sorry should have explained that before making the change. We have discussed it int he last design meeting. ppl felt that multiple inheritance complicates things and would not be super useful. if there are requests later on, we could add it back. Here are the notes: #10566

@mhegazy mhegazy added API Relates to the public API for TypeScript Breaking Change Would introduce errors in existing code labels Sep 13, 2016
@mhegazy mhegazy added this to the TypeScript 2.1 milestone Sep 13, 2016
@mhegazy mhegazy merged commit 873850b into master Sep 13, 2016
@mhegazy mhegazy deleted the configuration-inheritance branch September 13, 2016 21:30
@microsoft microsoft locked and limited conversation to collaborators Jun 19, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Reviewers
No reviews
Assignees
No one assigned
Labels
API Relates to the public API for TypeScript Breaking Change Would introduce errors in existing code
Projects
None yet
Milestone
TypeScript 2.1
Development

Successfully merging this pull request may close these issues.
7 participants
@weswigham @clavecoder @mhegazy @sandersn @chuckjaz @basarat @msftclas