Closed fuhrmanator closed 2 months ago
Further debugging leads to this module "express-flash-plus" being modeled as a Namespace rather than a Module, which seems odd. The problem is that an ImportClause needs to be created relative to a Module. The code crashes when fmxImportClause.setImportingEntity(fmxImporter);
runs and fmxImporter is a Namespace. I suspect the FQN for the Module is colliding with the Namespace. The FQNFunctions.getFQN
maybe needs to put the entity type (Namespace, Module) inside to avoid this.
const importerFullyQualifiedName = FQNFunctions.getFQN(importer);
const fmxImporter = this.famixRep.getFamixEntityByFullyQualifiedName(importerFullyQualifiedName) as Famix.Module;
fmxImportClause.setImportingEntity(fmxImporter);
I tried reverse lookup with fmxElementObjectMap and it returns a Famix.Namespace rather than Famix.Module. A dump of the keys() for that structure reveals NO modules. AST Viewer shows clearly a ModuleDeclaration in TSMorph.
Possibly need to have an isAmbient
property for Famix.Module.
Proposal: Drop Famix.Namespace and use Famix.Module (only) with isAmbient, isModule, isNamespace.
In TypeScript's AST there is no difference (they're all Module).
EDIT: This bug is related to ambient modules, which are used in declaration files (
.d.ts
). They're a special case that is not handled properly.The importer finds the following file (in the log210-jeu-de-des-express-typescript` project) and it's identified as a ScriptElement (according to the debugger), whereas I think it should be a Module (because it has import/export statements in a namespace).