Next.JS: makes build consume max heap memory

[statusunknown418]

Running OS

MacOS

Running Node Version

20.17

Description

I'm completely blocked from using this in a next route handler (next 15) as it just won't compile and instead throw this error

<--- Last few GCs --->

[24780:0x138008000]   108368 ms: Mark-Compact 4062.9 (4140.2) -> 4061.2 (4142.8) MB, 985.79 / 0.00 ms  (average mu = 0.330, current mu = 0.004) allocation failure; scavenge might not succeed
[24780:0x138008000]   110576 ms: Mark-Compact 4065.2 (4142.8) -> 4063.2 (4152.8) MB, 2203.71 / 0.00 ms  (average mu = 0.153, current mu = 0.002) allocation failure; scavenge might not succeed


<--- JS stacktrace --->

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----

 1: 0x1049db5a4 node::OOMErrorHandler(char const*, v8::OOMDetails const&) [/Users/a3tech/.nvm/versions/node/v20.17.0/bin/node]
 2: 0x104b6404c v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [/Users/a3tech/.nvm/versions/node/v20.17.0/bin/node]
 3: 0x104d38720 v8::internal::Heap::GarbageCollectionReasonToString(v8::internal::GarbageCollectionReason) [/Users/a3tech/.nvm/versions/node/v20.17.0/bin/node]
 4: 0x104d371fc v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/Users/a3tech/.nvm/versions/node/v20.17.0/bin/node]
 5: 0x104d2da14 v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/Users/a3tech/.nvm/versions/node/v20.17.0/bin/node]
 6: 0x104d2e274 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/Users/a3tech/.nvm/versions/node/v20.17.0/bin/node]
 7: 0x104d132e4 v8::internal::Factory::NewFillerObject(int, v8::internal::AllocationAlignment, v8::internal::AllocationType, v8::internal::AllocationOrigin) [/Users/a3tech/.nvm/versions/node/v20.17.0/bin/node]
 8: 0x1050faff4 v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [/Users/a3tech/.nvm/versions/node/v20.17.0/bin/node]
 9: 0x105458c44 Builtins_CEntry_Return1_ArgvOnStack_NoBuiltinExit [/Users/a3tech/.nvm/versions/node/v20.17.0/bin/node]
10: 0x1054593fc Builtins_StringAdd_CheckNone [/Users/a3tech/.nvm/versions/node/v20.17.0/bin/node]
11: 0x10a6ebe88 
12: 0x10a990be4 
13: 0x10a98e784 
14: 0x10a812218 
15: 0x10a9a43e4 
16: 0x10a96ddd4 
17: 0x10a9b116c 
18: 0x10a96dd1c 
19: 0x10a773a6c 
20: 0x10a7733d0 
21: 0x1053ce50c Builtins_JSEntryTrampoline [/Users/a3tech/.nvm/versions/node/v20.17.0/bin/node]
22: 0x1053ce1f4 Builtins_JSEntry [/Users/a3tech/.nvm/versions/node/v20.17.0/bin/node]
23: 0x104ca5bc8 v8::internal::(anonymous namespace)::Invoke(v8::internal::Isolate*, v8::internal::(anonymous namespace)::InvokeParams const&) [/Users/a3tech/.nvm/versions/node/v20.17.0/bin/node]
24: 0x104ca5014 v8::internal::Execution::Call(v8::internal::Isolate*, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, int, v8::internal::Handle<v8::internal::Object>*) [/Users/a3tech/.nvm/versions/node/v20.17.0/bin/node]
25: 0x104b7f904 v8::Function::Call(v8::Local<v8::Context>, v8::Local<v8::Value>, int, v8::Local<v8::Value>*) [/Users/a3tech/.nvm/versions/node/v20.17.0/bin/node]
26: 0x104904fa0 node::InternalMakeCallback(node::Environment*, v8::Local<v8::Object>, v8::Local<v8::Object>, v8::Local<v8::Function>, int, v8::Local<v8::Value>*, node::async_context) [/Users/a3tech/.nvm/versions/node/v20.17.0/bin/node]
27: 0x10491b068 node::AsyncWrap::MakeCallback(v8::Local<v8::Function>, int, v8::Local<v8::Value>*) [/Users/a3tech/.nvm/versions/node/v20.17.0/bin/node]
28: 0x1049e0d80 node::fs::FSReqCallback::Resolve(v8::Local<v8::Value>) [/Users/a3tech/.nvm/versions/node/v20.17.0/bin/node]
29: 0x1049e2848 node::fs::AfterScanDir(uv_fs_s*) [/Users/a3tech/.nvm/versions/node/v20.17.0/bin/node]
30: 0x1049d5430 node::MakeLibuvRequestCallback<uv_fs_s, void (*)(uv_fs_s*)>::Wrapper(uv_fs_s*) [/Users/a3tech/.nvm/versions/node/v20.17.0/bin/node]
31: 0x1053abb00 uv__work_done [/Users/a3tech/.nvm/versions/node/v20.17.0/bin/node]
32: 0x1053af550 uv__async_io [/Users/a3tech/.nvm/versions/node/v20.17.0/bin/node]
33: 0x1053c1628 uv__io_poll [/Users/a3tech/.nvm/versions/node/v20.17.0/bin/node]
34: 0x1053afb14 uv_run [/Users/a3tech/.nvm/versions/node/v20.17.0/bin/node]
35: 0x1049056f0 node::SpinEventLoopInternal(node::Environment*) [/Users/a3tech/.nvm/versions/node/v20.17.0/bin/node]
36: 0x104a1b3f0 node::NodeMainInstance::Run(node::ExitCode*, node::Environment*) [/Users/a3tech/.nvm/versions/node/v20.17.0/bin/node]
37: 0x104a1b104 node::NodeMainInstance::Run() [/Users/a3tech/.nvm/versions/node/v20.17.0/bin/node]
38: 0x1049a2fa0 node::Start(int, char**) [/Users/a3tech/.nvm/versions/node/v20.17.0/bin/node]
39: 0x1952c6b98 start [/usr/lib/dyld]

Expected behavior

Steps to reproduce

IT should let me build my app

Were you able to verify it by using (and changing) the examples?

No

If yes, which changes did you apply?

Other details

[alexandercerutti]

Hello @statusunknown418, thanks for using passkit-generator.

I am kind of aware of an issue with Next.

I think your issue is the same as #244, for which we weren't able to find a solution, I'm sorry.

I honestly don't know how to help you with this, as this is very weird. We might have hit some weird case of NextJS, even if they seem to be aware of possible memory issues.

I could suggest you to try with the last LTS version of Node, but I don't think something will change.

[statusunknown418]

@alexandercerutti yes just saw the issue, the current project I'm working on requires to create passes, do you prob know any alternative as to how to do this with other lib or maybe by hand?

[statusunknown418]

@alexandercerutti actually there's an example of it using CF workers in this repo, do you know if that's still working as expected?

[alexandercerutti]

In the wiki, in the paragraph for generating certificates, on the bottom, there are instructions for what you are asking.

Can't you just opt out Next or use some other service instead?

(I'll be unreachable for the next 8 hours, I think)

[statusunknown418]

@alexandercerutti yea that's the reason why I was asking if it'd work with workers for example

[alexandercerutti]

Sorry, I missed your comment on workers.

Yes, for what I know it still works. I've updated the example a few months ago.

If it doesn't, we might try to understand why.

Let me know

[ttiimmaahh]

I'm facing the same issue now. Locally I can bypass by just allocating more memory, but I'm unable to do any builds in Vercel. Makes me sad. I'll keep an eye on this if you post any potential updates that might help.

[arian81]

If anyone else is facing this issue, you can use version 3.2.0 of this library with any version of Next.js and it will be fine. Some change in 3.3.0 makes it cause the heap issue on Next.js 14.0 and above. This issue only happens on webpack (for me at least). It works fine with Turbopack.

[alexandercerutti]

To all of you: I actually never used seriously Next.JS.

I tried bootstrapping a project as example with it, that imports only passkit-generator.
I set up an API Route in this Next project with:

• Node 22
• "type": "module" in the package.json
• Webpack
• Next 15 (latest)

It seems working perfectly fine - at least locally.

I can run in and I can build it.

---

What you all guys are using, if I understood correctly, is the Server Actions.

So, my main questions is: what is preventing you from using or switching to API Routes? Is there any limitation I'm not aware of?

I feel like Server Actions is not suitable to be used with passkit-generator when API Routes fits perfectly (at least, apparently).

I also tried to replicate the repro case sent in #244, but after removing from the compiled version all the node: imports (dunno why they are apparently unsupported?), and mmoving back to fs.promises.lstat (for example) I get things like:

 ⨯ ../../lib/esm/getModelFolderContents.js:2:1
Module not found: Can't resolve 'fs'
  1 | import * as path from "path";
> 2 | import fs from "fs";
    | ^
  3 | import * as Utils from "./utils.js";
  4 | import * as Messages from "./messages.js";
  5 | /**

And I'm not exactly understanding why you don't.
What detail am I missing exactly?

[alexandercerutti]

@arian81 @ttiimmaahh @statusunknown418 @cody-white may I have a feedback from you please? I'd like to understand if I have to fix something or what.

Let me know!
Thank you

[statusunknown418]

@arian81 @ttiimmaahh @statusunknown418 @cody-white may I have a feedback from you please? I'd like to understand if I have to fix something or what.

Let me know!
Thank you

As I've added in my previous comment there seem to be an edge case reached on nextjs when trying to deploy/build that's preventing us from using passkit generator, not sure if the issue still persists in the latest version of next tho, will be able to test in the next days

[alexandercerutti]

@statusunknown418 Thank you for your reply. However, I wanted a feedback on my initial analysis: you are (or were you) using server actions instead of API Routes, isn't it? I need to understand why I can't set them up exactly, if anyone has an idea 🤷‍♂️

[statusunknown418]

hey @alexandercerutti I think i stopped working on this some time ago, but actually no, I wasn't using server actions, I just used a plain route handler to set up the passkit generator

Edit: I will however go back to work on it right now

[alexandercerutti]

@statusunknown418 any updates on this? I'm still trying to understand if there's a way I could reproduce the problem and if what I did is actually correct or wrong. Thanks.