Typescript: TS4023: Exported variable 'X' has or is using name 'Y' from external module 'a/file/path' but cannot be named
I'm attempting to create a set of external TypeScript modules as follows:
// ClassA.ts
export default class ClassA {
public method() { return true; }
}
// ModuleB.ts
import ClassA from './ClassA';
var moduleB = {
ClassA: ClassA
};
export default moduleB;
// ModuleA.ts
import moduleB from './ModuleB';
var moduleA = {
moduleB: moduleB
}
export default moduleA;
The idea is that this will be compiled down and supplied as a library. The plan is that the consumer of the library will instantiate an instance of ClassA as follows:
import moduleA from './ModuleA';
var anInstance = moduleA.moduleB.ClassA();
This looks as though it is compiling down to the expected JS, but I'm getting an error compiler error which I'm struggling to find further information about.
Using tsc v1.6.2
.../src/ModuleA.ts(3,5): error TS4023: Exported variable 'moduleA' has or is using name 'ClassA' from external module ".../src/ClassA" but cannot be named.
Can anyone here shed any light on this issue? Does what I'm trying to do make sense?
janakerman
All 24 comments
Oh - if this isn't a suitable place to ask this question. Please let me know and I'd be happy to post it on another medium.
janakerman
on 18 Nov 2015
FWIW you'll usually get faster answers on Stack Overflow, but we do field well-phrased questions here.
The problem here is that you're using the --declaration flag, but have not provided a way for the compiler to do its job.
When trying to emit ModuleA.d.ts, the compiler needs to write an object type literal (e.g. { moduleB: { classA: *mumble?* } }) representing the shape of the module. But there isn't a name in scope that refers directly to classA, so it the type "cannot be named" and there's an error.
If you add an import of ClassA to ModuleA.ts, the error should go away.
RyanCavanaugh
on 18 Nov 2015
Hi Ryan - thanks for the advice RE stack overflow and the advice - adding the import to ModuleA got things compiling as expected.
A little context here - my goal here is indeed to generate declarations for my external modules. (Something I believe isn't quite working yet? #5039?) This import may be completely necessary but It feels a little strange for ModuleA to need to import the symbols that moduleB already exports. The result is that every time I add to ModuleB's object export, I'll need to add the import to ModuleA - either directly:
import {moduleB} from './moduleB';
import {ClassA} from './ClassA';
Or via ModuleB (in an effort to reduce specifying paths for ClassA in both places):
import {moduleB, ClassA} from './moduleB';
I know very little about the TS compiler - so maybe what I'm saying is completely unrealistic, but at first thought it feels like the compiler could deduce that ModuleB is exporting an object with N symbols on it, so ModuleA needs those symbols? The import information for ModuleB is already there - could ModuleA use that? Or would that be impossible because the import for ClassA is completely internal to ModuleB, so there's no way that the compiler can deduce the type for ClassA when creating definitions for ModuleA?
Thank you again for taking the time to answer. I've sorted my problem now so the above is mainly curiosity - there's no rush to answer.
janakerman
on 23 Nov 2015
I'm not sure exactly what you're saying. What should ModuleA.d.ts look like in this proposal?
RyanCavanaugh
on 23 Nov 2015
The compiler will not add dependencies (i.e. import statements) that did not exist in the user code when it emits declarations. the error you are getting means that the compiler is trying to write a type annotation for an exported declaration but could not. this can have one of two reasons, either the name is not accessible, i.e. not imported in the current module, or there is a declaration that is shadowing the original declaration.
in both cases, your work around is to add explicit type annotation, if you add any type annotation, it will be emitted verbatim in the output; the other option is to make sure the name is accessible, i.e. you have an import to the module, and you understand what that means for your users that are importing your module.
mhegazy
on 2 Dec 2015
@mhegazy said:
The compiler will not add dependencies (i.e. import statements) that did not exist in the user code when it emits declarations.
The problem is that I don't always need the import statements in the code (obviously, since it works without --declarations), and including them is noisy, causing things like tslint to complain about the "unused import". I can see why you wouldn't want the compiler to add dependencies to emitted javascript, but what's the problem with adding them to emitting declarations?
cwalv
on 29 Jun 2016
feel free to log an issue to track this suggestion. the rational was imports are a declaration of dependency, and the compiler should not create one for you unless you instruct it to do.
mhegazy
on 29 Jun 2016
This could have deeper consequences.
Consider moduleA -> moduleB -> moduleC -> moduleD.
moduleB is the one that needs to do import { ABC } from 'moduleA' to get around this issue.
When moduleC uses moduleB and export its signature, it again fails to compile because moduleB needs ABC from moduleA but this time moduleB didn't export it.
This means either:
moduleCneeds to have a hard dependency ofmoduleAand importABCmoduleBneeds to not just import but also re-exportABCand thenmoduleCimports it.
If moduleD does similar things, then basically you need to know the whole chain of dependencies.
I wasn't able to test this to prove that it is the case because I'm using typings and there is an issue blocking me so: https://github.com/typings/typings/issues/625~~
EDIT: I am able to reproduce it and indeed my moduleD needs to reference moduleA to do import.
In my example:
moduleA=>reduxmoduleB=>redux-thunkmoduleC=> custom code on top ofredux-thunkmoduleD=> some libraryABC=>Dispatchinterface inredux
unional
on 9 Jul 2016
I have the same problem described by @unional
Offirmo
on 11 Sep 2016
Please reopen this issue, the issues outlined by @unional are very realistic and this makes it very hard to add any intermediate/helper libs on top of libraries while using the same types as the original module we are re-exporting.
frederickfogerty
on 27 Sep 2016
Issue https://github.com/Microsoft/TypeScript/issues/9944 tracks adding the import at the declaration emit phase.
mhegazy
on 28 Sep 2016
Thank!
unional
on 28 Sep 2016
The problem with adding the import is that with noUnusedLocals the compiler will complain about the type not being used. I could add an explicit type annotation, but then I don't get inference. Example:
class Whatever {
fetch(uri: string): Promise<void> { }
ensureFetched = MemoizedFunction<(uri: string) => Promise<void>> = memoize((uri: string) => this.fetch(uri))
}
I would like to omit type annotation for ensureFetched
felixfbecker
on 20 Mar 2017
rohmanhm
on 7 Jul 2017
I found a workaround for this:
in tsconfig: include: [ ..., "node_modules/@your_scope/your_library" ]
good luck and have fun :smiley:
salim7
on 17 Oct 2017
@salim7 this slows down your compilation times (because you're recompiling a library that should've already been compiled) and forces you to use the least common denominator of strictness settings with the target library.
pelotom
on 17 Oct 2017
@mhegazy the problem has reproduced in next scenario:
import * as Foo from "./Foo";
export class Bar {
baz = new Foo.Baz(); // Compiler forgot "Foo." prefix in the type, and throws this error, because "Baz" without perfix is not imported.
getBaz() { // All the same
return new Foo.Baz();
}
}
Solution is specify type explicit:
import * as Foo from "./Foo";
export class Bar {
baz: Foo.Baz = new Foo.Baz(); // ok
getBaz(): Foo.Baz { // ok
return new Foo.Baz();
}
}
PFight
on 29 Oct 2017
I can not get this to reproduce using the sample above. please file a new bug, and provide more context to be able to reproduce the issue.
mhegazy
on 30 Oct 2017
@PFight Thank you! That was it for me!
mohyeid
on 10 Dec 2017
I have just faced this issue when using:
export { IMyInterface } from './file'
````
The solution was to do this:
```ts
import { IMyInterface } from './file'
export { IMyInterface }
But this really shouldn't be necessary tbh.
brunolemos
on 15 Jan 2018
Did anyone figured out how to deal with noUnusedLocals ?
yordis
on 23 Jan 2018
@yordis // @ts-ignore
pelotom
on 23 Jan 2018
@pelotom yeah this is completely my fault,
I was thinking on one thing and I wrote something else.
Did Typescript fixed the issue between noUnusedLocals and the declarations?
yordis
on 23 Jan 2018
My current workaround, which feels like a total pain to me,
import {SomeInterface} from "./SomeFile";
const _dummySomeInterface : undefined|SomeInterface = undefined;
_dummySomeInterface;
//Code that implicitly uses SomeInterface
Avoids noUnusedLocals, allows type inference for generic interfaces, too, where possible.
AnyhowStep
on 8 Feb 2018
Related issues
uber5001
·
3Comments
zhuravlikjb
·
3Comments
Zlatkovsky
·
3Comments
bgrieder
·
3Comments
DanielRosenwasser
·
3Comments
Most helpful comment
FWIW you'll usually get faster answers on Stack Overflow, but we do field well-phrased questions here.
The problem here is that you're using the
--declarationflag, but have not provided a way for the compiler to do its job.When trying to emit
ModuleA.d.ts, the compiler needs to write an object type literal (e.g.{ moduleB: { classA: *mumble?* } }) representing the shape of the module. But there isn't a name in scope that refers directly toclassA, so it the type "cannot be named" and there's an error.If you add an
importofClassAtoModuleA.ts, the error should go away.