TypeError: Cannot read property getInstanceProperties' of undefined

[gustavopch]

Try to create entities in files with same name but in different folders, like:

• category/entities.ts
• product/entities.ts
• user/entities.ts

and you'll get the following error when initializing:

UnhandledPromiseRejectionWarning: TypeError: Cannot read property getInstanceProperties' of undefined

Investigating a bit, I found that TypeScriptMetadataProvider creates a map of source files keyed by the filename, causing some kind of conflict for the above mentioned case where multiple files have the same name but are on different folders.

[gustavopch]

A possible solution (https://github.com/mikro-orm/mikro-orm/blob/master/lib/metadata/TypeScriptMetadataProvider.ts#L27):

- const file = meta.path.match(/\/[^\/]+$/)[0].replace(/\.js$/, '.ts');
+ const file = meta.path.split(process.cwd())[1].replace(/\.js$/, '.ts');

That way file would be the path relative to the project root and keys wouldn't conflict. Not sure about side-effects.

[B4nan]

Currently entity name has to be unique, but your approach is about having multiple entities in the entities.ts file, right?

[gustavopch]

@B4nan Yes. I'm structuring my project in modules, so that product/entitites.ts would have all product-related entities, user/entities.ts would have all user-related entities etc.

[B4nan]

I don't think that is currently supported, it's definitely more complicated than your proposed change. ORM needs to be able to tell the entity name based on the file name and vice versa so it can find the TS source file for type sniffing via reflection.

I would suggest to have each entity in dedicated file and then re-export them in your entities.ts file (generally one would probably call it index.ts). That should be compatible with what you want (you will have single access point for all entities from given module, while every entity will be defined in its own file.

BTW you could also try to specify all types manually via type and entity decorator options. That way ts-morph won't be even used for reflection (as no reflection will be needed).

[gustavopch]

I don't think that is currently supported, it's definitely more complicated than your proposed change. ORM needs to be able to tell the entity name based on the file name and vice versa so it can find the TS source file for type sniffing via reflection.

I would suggest to have each entity in dedicated file and then re-export them in your entities.ts file (generally one would probably call it index.ts). That should be compatible with what you want (you will have single access point for all entities from given module, while every entity will be defined in its own file.

BTW you could also try to specify all types manually via type and entity decorator options. That way ts-morph won't be even used for reflection (as no reflection will be needed).

In fact, the problem is bigger than what I thought. I'll follow your suggestion to have individual files with barrel export. I'll let you decide whether to close this issue or not as I don't know whether you'd be interested to ship this change with v3.

[B4nan]

I will add validation for such case so it will throw a bit more informative error about the requirement for unique file names in v3. Will close this once it's implemented.

[B4nan]

Closing as resolved. Available for testing via next tag.