Skip to content

Importing large export assignment object causes Maximum call stack size exceeded #31824

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

Closed
AnyhowStep opened this issue Jun 8, 2019 · 2 comments · Fixed by #32097
Closed
Assignees
Labels
Bug A bug in TypeScript Fix Available A PR has been opened for this issue

Comments

@AnyhowStep
Copy link
Contributor

AnyhowStep commented Jun 8, 2019

TypeScript Version: 3.5.1

Search Terms: import, export assignment, export =, call stack

Code

This crashes tsc,

//npm install --save [email protected]
//`ts-node ./index.ts` works fine
//`tsc` gives `Maximum call stack size exceeded`
//`"type-mapping/fluent"` is a file that uses `export =`
//to export an object with many properties
import * as tm from "type-mapping/fluent";
console.log(tm);

This works fine,

//npm install --save [email protected]
//`ts-node ./index.ts` works fine
//`tsc` also works fine
//`"type-mapping"` is a file that uses `export *`
//to export many objects, even more than "type-mapping/fluent"
import * as tm from "type-mapping";
console.log(tm);

Expected behavior:

tsc should compile fine in both cases.

"type-mapping/fluent" uses export = to export a single object with many properties (141 properties).

However, the number of "things" exported is less than the amount exported
by "type-mapping", which uses export * (178, excluding interfaces and typedefs).

So, this makes me suspect that the problem is export =.
However, I simply have to use export = because "type-mapping/fluent" is generating these properties during run-time. (During compile-time, the export is a mapped object type)

Actual behavior:

Maximum call stack size exceeded with "type-mapping/fluent" and export =.

Works fine with "type-mapping" and export *

Related Issues: Not that I could find

@AnyhowStep
Copy link
Contributor Author

AnyhowStep commented Jun 8, 2019

The export is created here,
https://github.com/AnyhowStep/type-mapping/blob/1a999792f00fe25d2d3d1038d48b857a82b94219/src/fluent-lib/non-generic.ts

It is exported here,
https://github.com/AnyhowStep/type-mapping/blob/1a999792f00fe25d2d3d1038d48b857a82b94219/src/fluent-lib/index.ts

And here,
https://github.com/AnyhowStep/type-mapping/blob/1a999792f00fe25d2d3d1038d48b857a82b94219/fluent.d.ts


If I want to convert this to export *, I have to manually copy-paste code (and tweak) for possibly 100+ functions.


I've also noticed that when I use import * as tm from "type-mapping/fluent";, VS code will hang for a bit at times. And then I get an error saying the TS extension has crashed.

Restarting VS code lets it run fine again for a while before crashing again.

@AnyhowStep
Copy link
Contributor Author

AnyhowStep commented Jun 8, 2019

I just made a workaround for large export = objects causing tsc to crash.

I wrote a script to generate a file that uses export *, instead of export =

https://github.com/AnyhowStep/type-mapping/blob/13d9a96241d91d0e486ee4e8194ad163cce3986c/script/src/generate-fluent-lib-export.ts


So, fluent-lib/non-generic.ts still does its run-time wrapping of 100+ functions, and uses export =

But fluent-lib/index.ts uses export {/*list of function names*/} from "./non-generic";.

This way, I side-step the issue


I just published as version 1.1.5 and tested it and it seems to work without crashing now.
I'll have to test some more and see if there are any lingering side-effects.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug A bug in TypeScript Fix Available A PR has been opened for this issue
Projects
None yet
4 participants