-
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
Object detection for "Exported variable has or is using name
from external module"
#5938
Comments
A simplified repro is available in #8612 |
#8612 is what I'm trying to do. What is the difficulty of fixing this issue? Or, is there any way to work around this so that all the exports from a group of files can be imported into the same namespace? |
Aha. All I have to do is reference the original file, even if I don't use that reference. So, before, I had this: ////// model/index.ts
export { Team } from './Team'
export { Game } from './Game'
export { Score } from './Score' ////// action/index.ts
import * as model from '../model'
// This declaration produces the "cannot be named" error
export const getTeam = (teamId: string): model.Team => {
// ...
} But if I add ////// action/index.ts
import * as model from '../model'
import * as __Team from '../model/Team' // Throwaway reference
// No more error!
export const getTeam = (teamId: string): model.Team => {
// ...
} It's less than ideal, but at least I can keep my |
if setting |
Right... but that's not what we want. It should work fine whether we generate declaration files or not. In my case, I need the declaration files to be generated, and this workaround has proven successful, but quite the pain. |
Any ETA on this? Thanks! |
Would love to see this one addressed, a bit pesky. |
At the very least, as a shorter-term solution, it'd be nice to see a compiler option that allows definition files to be generated, with definitions that "cannot be named" simply being omitted, or replaced with |
First step in getting more of the TypeScript compiler checks on to help prevent bugs. This flag is more aesthetics than behavioral; however, it does help debugging and navigating code when looking up references. Since so many of the models and actions were imported into classes and not used it made it appear that they were used by more classes. I did see a few issues around using Redux `connect` and microsoft/TypeScript#5938 It's related to trying to export Props which contains types from the Models class that were not explicitly imported. I believe this is because we are using the `returntypeof` instead of explicitly defining the interfaces. I noticed `connect` has generic overload <StateProps, DispatchProps, OwnProps> and it internally merges them all which is what I think we should be doing; however, currently don't have well established pattern so I left code as is.
First step in getting more of the TypeScript compiler checks on to help prevent bugs. This flag is more aesthetics than behavioral; however, it does help debugging and navigating code when looking up references. Since so many of the models and actions were imported into classes and not used it made it appear that they were used by more classes. I did see a few issues around using Redux `connect` and microsoft/TypeScript#5938 It's related to trying to export Props which contains types from the Models class that were not explicitly imported. I believe this is because we are using the `returntypeof` instead of explicitly defining the interfaces. I noticed `connect` has generic overload <StateProps, DispatchProps, OwnProps> and it internally merges them all which is what I think we should be doing; however, currently don't have well established pattern so I left code as is.
I've just started to move shared code from your /shared project folder to separate module and stuck with this issue. Very sad ! |
In case you missed it, there is a workaround to this issue if you're stuck. I posted it above. |
@robyoder - I'm running into this same issue but with a module that's not mine. Specifically - express. import * as express from "express";
let router = express.Router();
router.use(...);
export = router; recreates this issue for Thanks! |
Oh and I found a solution here - #9944 (comment) |
@theigor right, that's the solution. You could still use it as import { Router } from "express"; but you don't actually need to change any other code (to use |
@weswigham your fix is good for explicit re-exports like this: export { Team } from "./Team"; but TS still fails when using a star export like this: export * from "./Team"; I've pushed a simple project showing this issue: https://github.com/robyoder/tsctest |
@robyoder Wanna open a new issue with the new repro? The reason for that failure is different from the underlying reason the named reexports were failing. |
@weswigham done: #20657 |
With the following structure:
node_modules/a/default.d.ts
containing a typing and a functionnode_modules/a/package.json
containing atypings
field todefault.d.ts
src/default.ts
' re-exporting everything froma
and exporting new functionssrc/newFunctions.ts
using thesrc/default.ts
You get "exported variable has or is using name from external module" errors when using an object:
However, when you don't use an object the functionality works as expected:
Using
1.8.0-dev.20151204
. Full repo https://github.com/Deathspike/typescript-reference-bug-example/The text was updated successfully, but these errors were encountered: