Do you want to request a _feature_ or report a _bug_?
Bug
What is the current behavior?
When using 1.2.0, my project compiles fine.
If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via https://codesandbox.io/ or similar.
I don't know how to debug the problem to create a minimal reproduction.
What is the expected behavior?
Project to compile correctly (or at least show me typescript errors).
Which versions of fp-ts, and which browser and OS are affected by this issue?
Reproduced on Ubuntu 18.04 and a Mac using the same reasonably large project (which I can't share unfortunately).
$ npm --version
6.0.0
$ node --version
v10.0.0
[email protected]
Did this work in previous versions of fp-ts?
Yes. If I do npm i [email protected] then build, it works correctly. Building after npm i [email protected], 1.4.0 or 1.5.0 sit at 100% cpu usage on 2 cores for a few minutes, and eventually break with the following out of memory error:
Project is running at http://0.0.0.0:5002/
webpack output is served from /bundle/
Content not from webpack is served from /home/tom/workspace/<REDACTED>/public
404s will fallback to /index.html
Warning: The 'no-floating-promises' rule requires type information.
Warning: The 'no-for-in-array' rule requires type information.
Warning: The 'no-unused-variable' rule requires type information.
[at-loader] Using [email protected] from typescript and "tsconfig.json" from /home/tom/workspace/<REDACTED>/tsconfig.json (in a forked process).
Node#moveAfter was deprecated. Use Node#after.
Node#before is deprecated. Use Node#raws.before
<it sits here for a few minutes>
<--- Last few GCs --->
[2307:0x3cf5860] 106058 ms: Mark-sweep 1336.9 (1455.4) -> 1336.9 (1455.4) MB, 572.3 / 0.0 ms allocation failure GC in old space requested
[2307:0x3cf5860] 106673 ms: Mark-sweep 1336.9 (1455.4) -> 1336.9 (1432.9) MB, 614.0 / 0.0 ms last resort GC in old space requested
[2307:0x3cf5860] 107299 ms: Mark-sweep 1336.9 (1432.9) -> 1336.9 (1432.9) MB, 626.0 / 0.0 ms last resort GC in old space requested
<--- JS stacktrace --->
==== JS stack trace =========================================
0: ExitFrame [pc: 0x36c144b0427d]
Security context: 0x326c5c7a06a9 <JSObject>
1: instantiateList(aka instantiateList) [/home/tom/workspace/<REDACTED>/node_modules/typescript/lib/typescript.js:~33399] [pc=0x36c144feeba9](this=0x22a472a822e1 <undefined>,items=0x226d194dce59 <JSArray[1]>,mapper=0xda03027db1 <JSFunction (sfi = 0x159a1aec24f9)>,instantiator=0x27f5b082f441 <JSFunction instantiateSignature (sfi = 0x1a03369...
FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
1: node::Abort() [/home/tom/.nvm/versions/node/v10.0.0/bin/node]
2: 0x87b56c [/home/tom/.nvm/versions/node/v10.0.0/bin/node]
3: v8::Utils::ReportOOMFailure(char const*, bool) [/home/tom/.nvm/versions/node/v10.0.0/bin/node]
4: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [/home/tom/.nvm/versions/node/v10.0.0/bin/node]
5: v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationSpace) [/home/tom/.nvm/versions/node/v10.0.0/bin/node]
6: v8::internal::Runtime_AllocateInTargetSpace(int, v8::internal::Object**, v8::internal::Isolate*) [/home/tom/.nvm/versions/node/v10.0.0/bin/node]
7: 0x36c144b0427d
Some of my project's dependencies also depend on fp-ts at the same version as the root, others depend on ^1.5.0, but it works if my root project uses 1.2.0 then it compiles, and with later versions it does not.
I'm not really sure how to debug this further? Is there a way to enable additional debug output during build? Or find out where it is stuck in a loop / what is taking the time?
This is likely an upstream issue, looks like a typescript crash.
You may try to upgrade to [email protected] or file an issue in the TypeScript repo.
@Crashthatch it may also be the case you have several version of the same library; this is known to not be undetected by the compiler and lead to a lot of recursive compare between types and ultimately leading to memory exhaustion / crash (that can never goes well).
@sledorze I think that is likely. I will investigate tomorrow, try to dedupe and see if that fixes the problem. It's odd that changing only the installed version of fp-ts causes this issue to appear / disappear though.
npm install [email protected] && npm dedupe has fixed it, so I think @sledorze's analysis was correct.
I'm still not sure why changing the version of the fp-ts library was causing this problem (other packages must have had different versions of the same library, even when I was using [email protected]), but it's fixed now.
Thanks for the help.
Most helpful comment
@Crashthatch it may also be the case you have several version of the same library; this is known to not be undetected by the compiler and lead to a lot of recursive compare between types and ultimately leading to memory exhaustion / crash (that can never goes well).