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.

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

initial revision of external module augmentations #6213

Merged
merged 10 commits into from
Jan 16, 2016
Merged

Conversation

vladima
Copy link
Contributor

@vladima vladima commented Dec 23, 2015

Module augmentation is a declaration of ambient module that directly nested either in external module or in top level ambient external module.
Name of module augmentation is resolved using the same set of rules as module specifiers in import \ export declarations.
If name is successfully resolved to some external module then declarations in module augmentation are merged with declarations inside module using standard rules for declaration merging.
Module augmentations cannot add new items to the top level scope but rather patch existing declarations.

for example

// observable.ts
export class Observable<T> {}
// map.ts
import {Observable} from "./observable";
Observable.prototype.map = function () { /* ... */ }

declare module "./observable" {
    interface Observable<T> {
        map<U>(proj: (el: T) => U): Observable<U>;
    }
}
// consumer.ts
import {Observable} from "./observable";
import "./map";
let o: Observable<number>;
o.map(x => x.toFixed());

Here module map can declare that internally it will patch Observable type and add map function to it.

Fixes: #5269, #6022

Pending work:

  • - add syntactic support for augmenting global scope. Currently augmentation for the global scope is defined as ambient module with special name "/" but this is just a placeholder. The version that we ended up during the design meeting was:
// in external module
export {};
declare global {}

or

// in script file
declare module "array" {
    global {}
}

@@ -109,6 +109,7 @@ namespace ts {
let blockScopeContainer: Node;
let lastContainer: Node;
let seenThisKeyword: boolean;
let isSourceFileExternalModule: boolean;
Copy link
Member

Choose a reason for hiding this comment

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

I don't see this getting used anywhere apart from the later assignment.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

right, forgot to remove that. Thanks

// error should already be reported so all errors in the body of augmentation can be ignored.
const checkBody = isNameOfGlobalAugmentation(<LiteralExpression>node.name) || (getSymbolOfNode(node).flags & SymbolFlags.Merged);
if (checkBody) {
const globalAugmentation = isNameOfGlobalAugmentation(<LiteralExpression>node.name);
Copy link
Member

Choose a reason for hiding this comment

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

isGlobalAugmentation or augmentsGlobal

@DanielRosenwasser
Copy link
Member

What exactly is the recommended way to augment a default export? Is it possible in this implementation?

@vladima
Copy link
Contributor Author

vladima commented Dec 23, 2015

it is not possible

@DanielRosenwasser
Copy link
Member

This also appears to take care of #2784. You might want to take note and give a heads up on that issue when this goes in.

@@ -139,6 +141,14 @@ namespace ts {
allSourcesModuleElementDeclarationEmitInfo = allSourcesModuleElementDeclarationEmitInfo.concat(moduleElementDeclarationEmitInfo);
moduleElementDeclarationEmitInfo = [];
}

if (!isBundledEmit && isExternalModule(sourceFile) && sourceFile.moduleAugmentations.length && !resultHasExternalModuleIndicator) {
Copy link
Contributor

Choose a reason for hiding this comment

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

what about external modules with no exports or no module augmentation? soemthing like:

import {a} from "./mod";
// do something with a

Copy link
Contributor

Choose a reason for hiding this comment

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

i thought we will do this for any external module, that we never emitted any import, export, or module augmentation for.

@mhegazy
Copy link
Contributor

mhegazy commented Jan 13, 2016

👍

}
}
}
checkSourceElement(node.body);
}

function checkBodyOfModuleAugmentation(node: Node, isGlobalAugmentation: boolean): void {
Copy link
Member

Choose a reason for hiding this comment

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

This should be checkModuleAugmentationElement. It checks and element in the body, not the body itself.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@vladima
Copy link
Contributor Author

vladima commented Jan 14, 2016

build failure is related to #6478

@vladima
Copy link
Contributor Author

vladima commented Jan 14, 2016

@ahejlsberg done, do you have any other comments?

if (!reportError) {
if (isGlobalAugmentation) {
// global symbol should not have parent since it is not explicitly exported
reportError = symbol.parent !== undefined;
Copy link
Member

Choose a reason for hiding this comment

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

The error message below seems a bit odd for this case, but maybe it's fine.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

for global case we can easily lift this restriction since it is possible to add new entries to global scope from within a module. Currently the fact that we have it is only because of consistency in behavior for augmentations.

Copy link
Member

Choose a reason for hiding this comment

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

No sure I understand, maybe we're talking about different issues. This code is saying that you get an error when you have an exported member in a global augmentation block, right? I'm thinking it should never be valid to use export in a global augmentation block.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

the idea of this check is following: symbol.parent will be undefined if symbol was initially defined in the global scope. If symbol.parent is not undefined this means that this symbol was declared inside augmentation and will declare new entry in the global scope which is disallowed in current design

Copy link
Member

Choose a reason for hiding this comment

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

If symbol.parent is not undefined this means that this symbol was declared inside augmentation

Why is that so? symbol.parent is non-undefined when the symbol is exported, but it might still be declared inside the augmentation. I'm not getting this.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

symbols whose initial declaration is in global scope are never exported and symbol.parent for them is always undefined. if symbol.parent !== undefined this means that this symbol is exported from somewhere and as a consequence initially defined in augmentation not in global scope

@masaeedu
Copy link
Contributor

In map.ts: since the ambient module declaration advertises to the compiler that Observable<T> has a map member, would you be able to attach a function of the appropriate kind to the prototype without casting to <any>?

else {
// this symbol contains only merged content from external modules and augmentations so it should always be exported (parent !== undefined)
// and parent should have value side (valueDeclaration !== undefined)
Debug.assert(symbol.parent !== undefined && symbol.parent.valueDeclaration !== undefined);
Copy link
Member

Choose a reason for hiding this comment

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

I have a hard time reasoning about this.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

this assert is redundant. it basically says: augmentation can only change exported symbol (parent !== undefeind) that really has a declaration (not a virtual symbol like prototype) - this should always be the case. I'll remove it

Copy link
Member

Choose a reason for hiding this comment

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

So did you mean symbol.valueDeclaration !== undefined? You currently have symbol.parent.valueDeclaration.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

symbol.parent.valueDeclaration - is an augmentation: declare module .... symbol.valueDeclaration is declaration inside the augmentation. Currently we report error if container that this symbol is module augmentation and not a normal external module

vladima added a commit that referenced this pull request Jan 16, 2016
initial revision of external module augmentations
@vladima vladima merged commit c6b0cf1 into master Jan 16, 2016
@vladima vladima deleted the moduleAugmentations branch January 16, 2016 05:28
@benlesh
Copy link

benlesh commented Jan 16, 2016

Awesome! Great stuff. Thank you!

@DanielRosenwasser
Copy link
Member

🎉 👏 👏 👏 👏 👏 👏 👏

@weswigham
Copy link
Member

👍

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Type generation for "modularly designed" libraries is hard
9 participants