ts-node and ts-node-dev don't work with cannot read property of undefined for everything locally imported.

[patarapolw]

But tsc && node -r esm . and nodemon -e ts -x 'tsc && node -r esm .' works OK.

Everything that I locally imported seems to be undefined with ts-node and I have tried madge and detect-circular-deps and they could not find a problem...

Real project -- https://github.com/patarapolw/rep2recall-web/blob/91e6f6a5870dca52010b4e569d4bb81f7c5be78f/package.json#L92 and https://github.com/patarapolw/rep2recall-web/blob/master/src/backend/server.ts

https://stackoverflow.com/questions/55753635/ts-node-and-ts-node-dev-dont-work-with-cannot-read-property-of-undefined-and

Might be exactly the same issue as #819

[exequiel09]

Any updates on this, I have the same problem. If i imported files from my project they are undefined but if I imported it from node_modules then they have values.

[cspotcode]

If we get a minimal reproduction, we can identify the root cause.

[exequiel09]

@cspotcode I have this minimal repro extracted from a project of mine. https://github.com/exequiel09/tsnode-bug
You can run the command: npm run rekt:ts-node-bug.
Basically what it does is apps/sample-app/rekt-ts-node.ts import the enum from libs/sample-lib/src/enums.ts but when imported the value in the apps/sample-app/rekt-ts-node.ts becomes undefined.
This has no circular imports by the way. It's only a small monorepo to begin with.

[cspotcode]

Excellent, if it's an enum problem, I suspect it has to do with enum elision. Const enums are removed from the emitted code unless preserveConstEnums is turned on. With typechecking, the compiler can inline the enum values. But in transpileOnly mode, it doesn't have type info, so preserveConstEnums is required. If you're trying to import an enum from a third-party library, that's where you hit trouble. If they didn't compile with preserveConstEnums, then you must use typechecking to get the type info.

…

On Thu, Jul 9, 2020, 7:19 PM Exequiel Ceasar Navarrete < ***@***.***> wrote: I have this minimal repro extracted from a project of mine. https://github.com/exequiel09/tsnode-bug You can run the command: npm run rekt:ts-node-bug. Basically what it does is apps/sample-app/rekt-ts-node.ts import the enum from libs/sample-lib/src/enums.ts but when imported the value in the apps/sample-app/rekt-ts-node.ts becomes undefined — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#822 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAC35ODK3HBIJ67PDTUZAHDR2ZF6RANCNFSM4HHW7TTA> .

[exequiel09]

It doesn't have to be enums. even a export const someVar = 1; will return undefined if imported. also it's plain enum not const enum coz i'm aware const enums are always removed.

[cspotcode]

It might be circular dependencies. IIRC the code emitted for `export * from ...` when converting to CommonJS doesn't handle circular dependencies. It could also be path mappings. Our README mentions another tool you can use to make node's resolver understand tsconfig "paths" mappings.

…

On Thu, Jul 9, 2020, 9:13 PM Exequiel Ceasar Navarrete < ***@***.***> wrote: It doesn't have to be enums. even a export const someVar = 1; will return undefined if imported — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#822 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAC35OGC77BAXFH2Q2GNDYDR2ZTMNANCNFSM4HHW7TTA> .

[exequiel09]

Yes the example contains path mappings. But I also tried no path mappings and still shows undefined. Plus it has no circular deps since only 2 files are involved, the imported and the file being executed.

[cspotcode]

Can you remove all non-essential elements of the reproduction? I see it includes some third-party dependencies. Are they necessary, or does the bug occur without them? The path mappings are not needed, so they should be removed as well. Anything that's not directly causing the bug is going to obscure it and prevent or delay us from implementing a bugfix.

[exequiel09]

Yep the bug does occur without them. I just included them because I use it in a project that uses TypeORM. But will strip off those other deps and regenerate the lockfile for you.

[exequiel09]

@cspotcode i pushed the changes without the typeorm related code plus there are now 2 examples there, one that imports a path-mapped code, and one that doesn't and both shows undefined. thanks!

[cspotcode]

Thanks. I'm guessing it's an issue with the esm library. Some googling found this:
standard-things/esm#580 (comment)

It seems esm needs to be loaded before ts-node.

Is there a reason you need to combine esm with ts-node? We support node's native ESM, and we can also compile your code down to CommonJS, so the esm module is not needed.

[exequiel09]

The import statements does not run without the esm module. This is needed when running TypeORM CLI utilities.

[exequiel09]

@cspotcode Ok your comment regarding CommonJS triggered me. I tried 2 scenarios with package.json type set to module:

1. With esm required and module set to esnext. Always undefined
2. With esm required and module set to commonjs. Returns the value as expected with or without the path mappings.

[exequiel09]

@cspotcode I tried also the same scenario without the package.json field type set to module and removed the esm requirement,

1. Without esm and module set to esnext. Errors out since it can't understand import statements
2. Without esm and module set to commonjs. Returns the value as expected with or without the path mappings.

[exequiel09]

@cspotcode I'll try first those 4 cases in my actual project. The 4 situations above were done using the reproduction repo.

[exequiel09]

@cspotcode both number 2 in my comments worked perfectly.

[cspotcode]

To summarize, esm was unnecessary and causing problems, right?

[cspotcode]

Pretty sure there's no action required for this.