You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Re-exporting namespace declarations in ES6 ambient declaration #4336
However, there doesn't seem to be an equivalent for ES6 modules:
declare module 'myLib'{exportdefaultMyLib;// this works for exporting the default, but other exported items in MyLib are not considered to be named exports of the ES6 moduleexport*fromMyLib;// this is essentially what I'm trying to accomplish}
The export = MyLib pattern is useful for making a module from a namespace without having to actually redeclare everything. The goal of the issue, in words, would be to allow making an ES6 module from a namespace without having to actually redeclare everything.
We have talked about 1. allowing external modules to access the global namespace (#4166) and 2. extending export * to namespaces. none has enough traction though.
I don't think #4166 applies here. I'm not trying to access the global namespace. I'm trying to re-export the exported declarations of an existing namespace.
Extending export * to namespaces might be applicable but it's hard to tell without more context on what you mean.
As far as a proposal, I would suggest new syntax for ambient ES6 module declarations which allows re-exporting declarations from an existing namespace. Let me first illustrate with an example that already works:
In that example, export * from "someLib" re-exports all exports from "someLib". Copied from #2242:
An export * declaration can be used to re-export all exports of another module. This is useful for creating modules that aggregate the exports of several other modules.
An export * doesn't re-export default exports or exports with names that are already exported from the current module. For example, the transform export in the module above hides any transform export in the re-exported modules.
My proposal would be the take that same concept and allow it for namespaces as well:
declarenamespaceSomeLib{exportvara: string;}declare module "myLib"{export*fromSomeLib;// <-- this is the new syntaxexportvarb: string;}
Looking at the spec, I don't think there's anything exported from a namespace that can't also be exported from a module. In fact, namespace seems to be a subset of module:
Any considerations on this?
I'm trying to expose some of the codebase with es6-modules as a global object. This object is constructed from nested namespaces. The problem is that most of the things to be exposed are in es6 modules and I just can't reexport them from namespace.
Something like the following would be extremely useful:
(re)exporting namespaces using existing export syntax would be helpful.
Exporting
exportnamespaceNameSpace{export{foo}from'./foo'}
Allowing the above, could it help getting rid of the annoying Export declaration is not permitted in a namespace error?
Would love to logically organise a large component using namespace and still maintain the ability to expose needed members to the outside...
Reacted by JD Conley, Konstantin Azizov, Stefan Burg, Shaun Luttin, Jan Melcher, Kevin Beal, c4605, David Lannoye, Greg Rozmarynowycz, Kirill Agalakov and 28 more
Oh! Ok! I came across this issue looking for a solution to this problem, but found later in my travels that there is actually a solution now.
I found 4529 which states that you can do export import Name = Value.
Activity
mhegazy commentedon Aug 17, 2015
so why use
export =then?jbrantly commentedon Aug 17, 2015
Mohamed Hegazy (@mhegazy) Sorry, I didn't understand your comment. Could you clarify?
The
export = MyLibpattern is useful for making a module from a namespace without having to actually redeclare everything. The goal of the issue, in words, would be to allow making an ES6 module from a namespace without having to actually redeclare everything.mhegazy commentedon Aug 17, 2015
We have talked about 1. allowing external modules to access the global namespace (#4166) and 2. extending
export *to namespaces. none has enough traction though.what is the proposal here?
jbrantly commentedon Aug 17, 2015
I don't think #4166 applies here. I'm not trying to access the global namespace. I'm trying to re-export the exported declarations of an existing namespace.
Extending
export *to namespaces might be applicable but it's hard to tell without more context on what you mean.As far as a proposal, I would suggest new syntax for ambient ES6 module declarations which allows re-exporting declarations from an existing namespace. Let me first illustrate with an example that already works:
In that example,
export * from "someLib"re-exports all exports from "someLib". Copied from #2242:My proposal would be the take that same concept and allow it for namespaces as well:
Looking at the spec, I don't think there's anything exported from a namespace that can't also be exported from a module. In fact, namespace seems to be a subset of module:
Assuming that's the case,
export * from SomeLibseems reasonable.The use case for this is to simplify writing declaration files for existing ES6 libraries (see #4337).
e-cloud commentedon Dec 3, 2016
(Re)exporting namespaces or interfaces is really reasonable.
current status
You can use the follow style:
a.d.ts
index.d.ts
However, you can't use it in a namespace which is incompatible with scene 3
And it usage is quite limited.
possible scene of re-exporting
For example, I may define several definiation files, assume the library name is MyLib:
a.d.ts
b.d.ts
scene 1 (re-export namespace as sub namespace)
index.d.ts (MyLib definition)
index.tests.ts
scene 2 (merge the namespaces)
index.d.ts (MyLib definition)
index.tests.ts
scene 3 (normal for node.js modules)
index.d.ts (MyLib definition)
index.tests.ts
scene 4 (like scene2 in scene3)
...
raveclassic commentedon Jan 16, 2017
Any considerations on this?
I'm trying to expose some of the codebase with es6-modules as a global object. This object is constructed from nested namespaces. The problem is that most of the things to be exposed are in es6 modules and I just can't reexport them from namespace.
Something like the following would be extremely useful:
FlippieCoetser commentedon Feb 19, 2017
(re)exporting namespaces using existing export syntax would be helpful.
Exporting
Allowing the above, could it help getting rid of the annoying Export declaration is not permitted in a namespace error?
Would love to logically organise a large component using namespace and still maintain the ability to expose needed members to the outside...
G07cha commentedon Jun 18, 2017
I'm currently using next workaround for interfaces:
This should work for classes as well, the only drawback is the fact that you need to rename variables.
tdeekens commentedon Jan 3, 2018
I would also align typings with small modules while re exporting them in a accumulating bigger module.
Griffork commentedon Feb 19, 2021
Oh! Ok! I came across this issue looking for a solution to this problem, but found later in my travels that there is actually a solution now.
I found 4529 which states that you can do
export import Name = Value.Like so: