-
Notifications
You must be signed in to change notification settings - Fork 12.6k
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
Reopening external modules broken in TS 1.5-alpha #2784
Comments
Don't think this is a bug. It isn't possible to have other exports in a module that uses I don't see the error "An export assignment cannot be used in a module with other exported elements" and I wouldn't expect to as there are no other exported elements. I do see the error "Property 'b' does not exist on type 'typeof "foo"'" and I think that is correct. |
Cool. I can verify that it did work.
It might just be the language service : I've uploaded the sample for testing : https://github.com/TypeStrong/atom-typescript-examples/tree/master/errorcases/reopenExternalModules This brings us back to the question: If I write an npm module and create a definition: declare module "foo" {
interface Foo {
a: number;
}
var _:Foo;
export = _;
} How can someone create another NPM module and provide enhancements for my Foo. Perhaps the answer is to use non instantiated modules in my definition so that they can be safely reopened and extended. Correct? |
I'm not entirely clear on what you're trying to model here, but certainly one way you could do it is to declare the declare module FooTypes {
export interface Foo {
a: number;
}
}
declare module "foo" {
var _: FooTypes.Foo;
export = _;
} And /// <reference path="./a"/>
declare module FooTypes {
export interface Foo {
b: number;
}
} Now, with my ES6 hat on, the above isn't a pattern I would recommend. In ES6, modules are non-extensible objects and you can't just jam properties onto them. Instead you declare a new module and use |
I'm seeing this same issue (in tsc 1.5.3) and I'd be very interested to hear of any workarounds there might be. I'm using a DefinitelyTyped declaration that has been written similarly to @basarat's example:
The problem is that one of the TSD module interfaces ( In my case the
Is there another way to add to this interface without modifying the main TSD definition file? |
I do not see other way around this. |
Same here. We went with wrapping those interfaces in a non instantiated module (i.e. modifying the original definitions) |
Can you not just edit your local copy of the .d.ts until the PR for the fix is taken? |
@danquirk it would be possible, but on my team we try to avoid checking in library code, and it would be pretty icky to check in a fork of a huge definitions file just to add a single line. |
I need to do this in order to use react-css-modules (https://github.com/gajus/react-css-modules), as it dynamically adds a property called styleName to React's HTMLAttributes definition. React definitions should not be extended to include the styleName attribute, as its the separate react-css-modules library that extends this. So it should be possible to extend interfaces in typescript modules (it's not just a matter of waiting for a PR to the definitions to be merged). I'm actually not sure how I use the react-css-modules library with typescript without modifying the react definitions? Do you have any tips @ahejlsberg ? Thanks! |
I believe we are modeling this scenario with #6213. |
Consider
a.d.ts
(which compiles fine in isolation) without any error:And
b.d.ts
that plans to add stuff to modulefoo
'sFoo
interface:With this we have two errors:
a.d.ts
gets an error onexport =
"An export assignment cannot be used in a module with other exported elements.b.d.ts
doesn't actually manage to add to theinterface Foo
as demonstrated by a test filetest.ts
:Discovered in DefinitelyTyped : DefinitelyTyped/DefinitelyTyped#4101 /cc @vvakame
The text was updated successfully, but these errors were encountered: