vite build error: out of memory

NOTE - PLEASE READ
This issue has affected a number of people. Please do not comment with comments along the lines of "I'm also hitting this", but add a thumbs up to the issue instead. We know this is an important issue and "me too" comments will only drown out the comments from people attempting to resolve this issue and will be hidden. Please note however that Vite is a community driven project and a fix may need to come from the community
For tips on working around the issue, please see https://rollupjs.org/guide/en/#error-javascript-heap-out-of-memory
Describe the bug
vite build error: out of memory.
Reproduction
https://github.com/Axeldeblen/realworld-big-build
Possible improvements
Reduce magic string memory usage when building source maps: https://github.com/Rich-Harris/magic-string/pull/161#issuecomment-607480189
Logs (Optional if provided reproduction)
<--- JS stacktrace --->
==== JS stack trace =========================================
0: ExitFrame [pc: 00007FF69790ABBD]
Security context: 0x01e6a86408d1
1: decode(aka decode) [000002AD02F874D1] [E:\vite-template\node_modules_rollup@2.40.0@rollup\dist\shared\rollup.js:~133] [pc=0000039464A55451](this=0x037824a004b1 ,0x017863480119 <Very long string[1502653]>)
2: decodedSourcemap(aka decodedSourcemap) [000002AD02F8A979] [E:\vite-template\node_modules_rollup<EMAIL_ADDRESS>FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
1: 00007FF696CD180F napi_wrap+119407
2: 00007FF696C787E6 v8::internal::OrderedHashTablev8::internal::OrderedHashSet,1::NextTableOffset+38102
3: 00007FF696C795E6 node::OnFatalError+438
4: 00007FF6974B5A6E v8::Isolate::ReportExternalAllocationLimitReached+94
5: 00007FF69749DC21 v8::SharedArrayBuffer::Externalize+833
6: 00007FF69734F3FC v8::internal::Heap::EphemeronKeyWriteBarrierFromCode+1436
7: 00007FF69735A640 v8::internal::Heap::ProtectUnprotectedMemoryChunks+1312
8: 00007FF697357154 v8::internal::Heap::PageFlagsAreConsistent+3204
9: 00007FF69734C953 v8::internal::Heap::CollectGarbage+1283
10: 00007FF69734AFC4 v8::internal::Heap::AddRetainedMap+2500
11: 00007FF69736C30D v8::internal::Factory::NewFillerObject+61
12: 00007FF6970CF76F v8::internal::interpreter::JumpTableTargetOffsets::iterator::operator=+1295
13: 00007FF69790ABBD v8::internal::SetupIsolateDelegate::SetupHeap+546925
14:<PHONE_NUMBER>A55451

Describe the bug
vite build error: out of memory.
Reproduction
Static directory memory is a bit large
System Info

vite version: 2.0.5
Operating System: windows 10
Node version:14.16.0
Package manager (npm/yarn/pnpm) and version: npm 6.14.9

Logs (Optional if provided reproduction)
<--- JS stacktrace --->
==== JS stack trace =========================================
0: ExitFrame [pc: 00007FF69790ABBD]
Security context: 0x01e6a86408d1
1: decode(aka decode) [000002AD02F874D1] [E:\vite-template\node_modules_rollup@2.40.0@rollup\dist\shared\rollup.js:~133] [pc=0000039464A55451](this=0x037824a004b1 ,0x017863480119 <Very long string[1502653]>)
2: decodedSourcemap(aka decodedSourcemap) [000002AD02F8A979] [E:\vite-template\node_modules_rollup<EMAIL_ADDRESS>FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
1: 00007FF696CD180F napi_wrap+119407
2: 00007FF696C787E6 v8::internal::OrderedHashTablev8::internal::OrderedHashSet,1::NextTableOffset+38102
3: 00007FF696C795E6 node::OnFatalError+438
4: 00007FF6974B5A6E v8::Isolate::ReportExternalAllocationLimitReached+94
5: 00007FF69749DC21 v8::SharedArrayBuffer::Externalize+833
6: 00007FF69734F3FC v8::internal::Heap::EphemeronKeyWriteBarrierFromCode+1436
7: 00007FF69735A640 v8::internal::Heap::ProtectUnprotectedMemoryChunks+1312
8: 00007FF697357154 v8::internal::Heap::PageFlagsAreConsistent+3204
9: 00007FF69734C953 v8::internal::Heap::CollectGarbage+1283
10: 00007FF69734AFC4 v8::internal::Heap::AddRetainedMap+2500
11: 00007FF69736C30D v8::internal::Factory::NewFillerObject+61
12: 00007FF6970CF76F v8::internal::interpreter::JumpTableTargetOffsets::iterator::operator=+1295
13: 00007FF69790ABBD v8::internal::SetupIsolateDelegate::SetupHeap+546925
14:<PHONE_NUMBER>A55451

I'm getting the same error on https://github.com/inkline/inkline/tree/inkline3 after updating from 2.0.0-beta.60 to 2.0.5.
It's definitely a memory leak. I've tried starting from a clean project and gradually added my code to it in order to find the issue. I discovered that it only happens when I rm -r node_modules, npm install and npm run dev. If I work on the project with Vite already initialised and cached, it won't happen. I know that because I've started from a clean project 5 times. Every time after I move the files over to the old location and go through the installation, it will crash.

For me at least, Vite was compiling my tests coverage folder which led to this heap error so I had to specify root: src in the config. Maybe optimizeDeps could also be set to exclude coverage but I haven't tried it.

I could only get it to work with node 15 on an Apple M1 without having to increase the max_old_space_size value. Either node 12 or 14 would run out of memory.

We're facing the same issue, although it only happens on my machine and all my colleagues have no issues.
When running npm run dev, node takes up 4G+ memory on the first run, whereas it doesn't even hit 500MB for my colleagues.
We aligned all node/npm/etc versions as best as we could, but the issue persists.
Here's the output of the system log:
  System:
    OS: macOS 11.2.3
    CPU: (8) x64 Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz
    Memory: 4.37 GB / 16.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 14.16.0 - ~/.nvm/versions/node/v14.16.0/bin/node
    Yarn: 1.22.5 - /usr/local/bin/yarn
    npm: 6.14.11 - ~/.nvm/versions/node/v14.16.0/bin/npm
    Watchman: 4.9.0 - /usr/local/bin/watchman
  Browsers:
    Chrome: 89.0.4389.128
    Edge: 89.0.774.77
    Firefox: 84.0.2
    Safari: 14.0.3
  npmPackages:
    @vitejs/plugin-vue: ^1.1.5 => 1.1.5
    vite: ^2.1.2 => 2.1.2

I'll post the stack trace soon, it just dipped under 4G so doesn't crap out, will try to make that happen again.

Even a Circle CI run: https://app.circleci.com/pipelines/github/vitejs/vite/3715/workflows/154262d9-1609-4f93-a362-41e50918cf11/jobs/3597

Running into this issue on my 8GB M1 macbook. Can we expect a fix for this soon?

@samuveth You should workaround this by using --max-old-space-size=<your-mem -512mb or so> for now

Also, just set it as an env variable and you don't have to call Vite's js script directly:
# where xxxx = (your memory in GiB) * 1024 - 512
export NODE_OPTIONS='--max-old-space-size=xxxx'

same problem +1

I think the "has work around" label should be removed and the priority of this issue should be increased.
--max-old-space-size=<your-mem -512mb or so> is a horrible hack.
I would consider this a severe bug worth avoiding Vite over.
The lack of priority leads me to believe it must only be affecting a minority of users; nevertheless, this is not dependable for production.

#stillhappens

ens...

contributions are welcome

would also help to get an actual simple reproduction in a github/stackblitz repo

I would check if its compiling a coverage folder, dist folder, or something else unintended.

For me, I was experiencing memory errors because of some heavy libraries used in my React application. I observed Vite was transforming over 7000 files every time I added these heavy libraries to the production build process.
To fix it, I had to find alternative ways to import those libraries or use their minified versions or import just the needed sub-packages for libraries with sub-packages like _lodash.
Lastly, disabling the source map in the Vite config reduced the memory needed to build my application by more than 500MB.

Same problem +1

I see some people are encountering this with vite dev. In that case, you should (1) connect the Chrome inspector to your Vite process and (2) pause the step debugger (shortly after starting the dev server and without loading anything in your browser). It's possible that you have a relatively complex circular directory symlink chain, and readdirp is being tricked into infinitely crawling those directories (but asynchronously, thereby avoiding a stack overflow). If the step debugger opens a readdirp file, you can be sure this is your issue. This is common if you're developing a chain of packages locally and linking one of them into your Vite project.
Using the server.watch.ignored option in Vite config, you can prevent chokidar (the file watcher that Vite uses) from watching the circular directory chain.

export NODE_OPTIONS='--max-old-space-size=512'

did help if building on a memory-limit device, like Raspberry Pi 3.
But I still believe some optimization would be great.

This is a critical issue and there is no one investigating it ? (didn't expect that from vite team :( )

Hi @nichita-pasecinic, please see this comment:

would also help to get an actual simple reproduction in a github/stackblitz repo

@aleclarson The issue is reproduceable on large codebase with lots of dependencies, I guess no one will leak the enterprise application source code just for the repro. It actually worked ok without any 'out of memory' errors until a specific commit (a very small one) that did not included any dependency or had other thinks that might request more memory for build time (previously was 2GB now increased to 4GB), it was added a single (and simple) react component and that's all.
I will try to recreate a repro with similar dependency, but there is as well a big codebase that might affect issue, I think you should try to investigate it too, because obviously is a big issues that can be just leaved open until someone will find a reproduction.

I believe this issue is reproducible with memory-limit device. In my case, raspberry pi 3 (1GB RAM). My spa is small, vite with naive-ui, date-fns, mitt. I do not mind it would take way longer than X86 workstation. But broken with GC error is frustrating. Hoping there could be some throttling mechanism implemented.

I am having the same issue on a rather large codebase with a lot of dependencies. The build process uses up towards 30GB of ram 😲  This is a serious memory leak and might have to move away from vite, which is sad cause the dev process is super fast and enjoyable.

@aleclarson The issue is reproduceable on large codebase with lots of dependencies, I guess no one will leak the enterprise application source code just for the repro. (...) .I will try to recreate a repro with similar dependency, but there is as well a big codebase that might affect issue, I think you should try to investigate it too, because obviously is a big issues that can be just leaved open until someone will find a reproduction.

@nichita-pasecinic since it makes sense that an enterprise app can't be opened to provide a repro, maybe your company or some of the other ones that are experiencing this problem could place some resources to investigate the issue and see if it is a problem in Vite or Rollup. In both projects, a PR to fix this would be highly appreciated.

which commit do you suspect is causing this memory issue?

@Niputi it is a simple component refactor, nothing really special, unfortunately I can't share organization source cod.
The commit is about adding a new component (~80lines) to just simplify another big component.

At https://github.com/sveltejs/kit/issues/4795, @Axeldeblen provided a repro (https://github.com/Axeldeblen/realworld-big-build) with sveltekit which is failing on the vite ssr build phase. It should be relevant here too as sveltekit doesn't do a lot of heavy lifting while Vite is building.

Hi Vite team, we're also experiencing this issue. All seemed fine until we added "autoprefixer": "^10.4.4" to our project. After that our memory usage from Vite builds more than tripled. I don't think it's that module but perhaps some common dependency? I was not able to identify a specific dependency in the tree which seemed to be the offender.
We're using:
"vite": "^2.8.6",
"vite-plugin-ssr": "^0.3.61"

You can set node to inspect in the sample project by updating package.json:
"build": "node --inspect<EMAIL_ADDRESS>build --verbose",

It looks to me like all the memory usage is instances of NodeBase being created by parseNode.

It looks like this stuff is being cached. I wonder if that's related to the memory leak?
https://github.com/rollup/rollup/blob/275dc2fa34e1aaad37a29360570dc85b1ba019a6/src/ModuleLoader.ts#L274

Given that it seems like this issue is coming from Rollup, I would recommend anyone who wants to see this fixed try to see if you can create a very large Rollup project which crashes similarly to the SvelteKit project, file a bug in the Rollup repository, and link it here. This is getting to be far enough away from the SvelteKit codebase that I don't have enough expertise to fix the issue and so it'd have to be reported to Rollup.

from Rollup for reference - https://rollupjs.org/guide/en/#error-javascript-heap-out-of-memory

export NODE_OPTIONS='--max-old-space-size=512'

Unluckily, this solution is not for me.

It's not related to codebase size or dependencies number. I've a small project with 16 dependencies and the issue occurs since my last commit, even with a max-old-space-size of 20GB.

@stillgbx would you be able to provide a reproduction?

@Niputi I'm currently trying to isolate the issue

@Niputi
For now, if I uncomment one of this import then the build breaks:

And I can see this warning:

It's probably related...

your message is not the same as the reported build errors for issue.
please open a new issue with a reproduction via vite.new or a github repository

because I stop the build to show you the warning message

then please provide a github repository or a reproduction via vite.new so it will be easier for us to look through

vite v2.9.9 building for production...
✓ 391 modules transformed.
✓ 603 modules transformed.
✓ 885 modules transformed.
✓ 896 modules transformed.
✓ 1120 modules transformed.
✓ 1344 modules transformed.
transforming (1538) node_modules\@fingerprintjs\fingerprintjs\dist\fp.esm.js(node:36892) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 beforeExit listeners added to [process]. Use emitter.setMaxListeners() to increase limit
(Use `node --trace-warnings ...` to show where the warning was created)
✓ 1584 modules transformed.
✓ 1813 modules transformed.
✓ 2043 modules transformed.
✓ 2255 modules transformed.
✓ 2482 modules transformed.
✓ 2709 modules transformed.
✓ 2936 modules transformed.
✓ 3163 modules transformed.
✓ 3390 modules transformed.
✓ 3616 modules transformed.
✓ 3844 modules transformed.
✓ 4071 modules transformed.
✓ 4298 modules transformed.
✓ 4535 modules transformed.
✓ 4765 modules transformed.
✓ 4990 modules transformed.
✓ 5230 modules transformed.
✓ 5433 modules transformed.
✓ 5670 modules transformed.
✓ 5888 modules transformed.
✓ 6113 modules transformed.
✓ 6341 modules transformed.
✓ 6568 modules transformed.
✓ 6795 modules transformed.
✓ 7022 modules transformed.
✓ 7258 modules transformed.
✓ 7476 modules transformed.
✓ 7697 modules transformed.
✓ 7930 modules transformed.
✓ 8167 modules transformed.
✓ 8396 modules transformed.
✓ 8612 modules transformed.
✓ 8838 modules transformed.
✓ 9064 modules transformed.
✓ 9302 modules transformed.
✓ 9535 modules transformed.
✓ 9746 modules transformed.
✓ 9973 modules transformed.
✓ 10199 modules transformed.
✓ 10427 modules transformed.
✓ 10654 modules transformed.
✓ 10881 modules transformed.
✓ 11108 modules transformed.
✓ 11335 modules transformed.
✓ 11562 modules transformed.
✓ 11799 modules transformed.
✓ 12016 modules transformed.
✓ 12243 modules transformed.
✓ 12470 modules transformed.
✓ 12705 modules transformed.
✓ 12936 modules transformed.
✓ 13166 modules transformed.
✓ 13391 modules transformed.
✓ 13620 modules transformed.
✓ 13835 modules transformed.
✓ 14059 modules transformed.
✓ 14296 modules transformed.
✓ 14513 modules transformed.
✓ 14750 modules transformed.
✓ 14978 modules transformed.
✓ 15194 modules transformed.
✓ 15421 modules transformed.
✓ 15648 modules transformed.
✓ 15849 modules transformed.
✓ 16072 modules transformed.
✓ 16327 modules transformed.
✓ 16556 modules transformed.
✓ 16783 modules transformed.
✓ 17010 modules transformed.
✓ 17237 modules transformed.
✓ 17465 modules transformed.
✓ 17666 modules transformed.
✓ 17928 modules transformed.
✓ 18161 modules transformed.
✓ 18384 modules transformed.
✓ 18599 modules transformed.
✓ 18797 modules transformed.
✓ 19053 modules transformed.
✓ 19290 modules transformed.
✓ 19522 modules transformed.
✓ 19734 modules transformed.
✓ 19961 modules transformed.
✓ 20188 modules transformed.
✓ 20425 modules transformed.
✓ 20642 modules transformed.
✓ 20864 modules transformed.
transforming (20895) src\components\mp-app-ui\mp-idle\helpers\axios.js
<--- Last few GCs --->

[36892:000001F7F719ADD0]    96796 ms: Mark-sweep 4017.3 (4129.4) -> 4003.9 (4127.1) MB, 3995.8 / 0.0 ms  (average mu = 0.099, current mu = 0.033) allocation failure scavenge might not succeed
[36892:000001F7F719ADD0]    96836 ms: Scavenge 4020.2 (4127.1) -> 4011.0 (4127.1) MB, 10.3 / 0.0 ms  (average mu = 0.099, current mu = 0.033) allocation failure
[36892:000001F7F719ADD0]    96887 ms: Scavenge 4020.0 (4127.1) -> 4014.3 (4131.4) MB, 40.0 / 0.0 ms  (average mu = 0.099, current mu = 0.033) task

<--- JS stacktrace --->

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 00007FF79B31013F v8::internal::CodeObjectRegistry::~CodeObjectRegistry+112495
 2: 00007FF79B29F396 DSA_meth_get_flags+65526
 3: 00007FF79B2A024D node::OnFatalError+301
 4: 00007FF79BBD19EE v8::Isolate::ReportExternalAllocationLimitReached+94
 5: 00007FF79BBBBECD v8::SharedArrayBuffer::Externalize+781
 6: 00007FF79BA5F61C v8::internal::Heap::EphemeronKeyWriteBarrierFromCode+1468
 7: 00007FF79BA6C2C9 v8::internal::Heap::PublishPendingAllocations+1129
 8: 00007FF79BA6929A v8::internal::Heap::PageFlagsAreConsistent+2842
 9: 00007FF79BA5BF19 v8::internal::Heap::CollectGarbage+2137
10: 00007FF79BA5A0D0 v8::internal::Heap::AllocateExternalBackingStore+2000
11: 00007FF79BA7EA06 v8::internal::Factory::NewFillerObject+214
12: 00007FF79B7B1CD5 v8::internal::DateCache::Weekday+1797
13: 00007FF79BC5F3E1 v8::internal::SetupIsolateDelegate::SetupHeap+494417
14: 00007FF79BC455F6 v8::internal::SetupIsolateDelegate::SetupHeap+388454
15: 000001F780A07E77

@Niputi here is a minimal test repo: https://github.com/stillgbx/vite-build-issue

PS: Like in my original project, I use a Web Worker (imported with the query suffix ?worker) and I realize now that it finally imports things that it (probably) shouldn't import. So for this case I would say it's a design issue introduced by the last commit. Nevertheless I hope that this test can help solve the original issue.

Can't believe this problem has existed for more than a year, I repeated this problem when build with source map.
I refer to the above scheme for temporary solution: NODE_OPTIONS='--max-old-space-size=4096' yarn serve

我用vue3 + vite2 + ts 重构了公司的一个中大型项目，现在打不了包，参照上面的解决方式分配了10G内存，还是打包失败😫

@guohui666 开sourcemap了吗？我那个开了sourcemap 巨大无比，关了就行了，但是我那个项目小。https://github.com/n9e/fe-v5

@guguji5 把sourcemap关掉了之后尝试了一下，还是一样的

@guohui666 如果解决了，一定分享一下solution哈。我怕我们项目代码越来越多，估计也有这问题

@stillgbx FYI Your issue is same with #7015. There is the following circular dependency which includes a worker.

workers/worker.js
services/service.js
helpers/helper.js
store/store.js
components/comp-1/store/store.js
components/comp-1/store/actions.js
workers/worker.js

Thank you @sapphi-red
Yes I identified that.
I still think vite should notify us of the circular dependency if it can detect it.

Describe the bug
vite build error: out of memory.
Reproduction
Static directory memory is a bit large，There are a lot of MP4 video files，600MB
System Info

vite version: 2.0.5
Operating System: windows 10
Node version:14.16.0
Package manager (npm/yarn/pnpm) and version: npm 6.14.9

Logs (Optional if provided reproduction)
<--- JS stacktrace --->
==== JS stack trace =========================================
0: ExitFrame [pc: 00007FF69790ABBD] Security context: 0x01e6a86408d1 1: decode(aka decode) [000002AD02F874D1] [E:\vite-template\node_modules_rollup@2.40.0@rollup\dist\shared\rollup.js:~133] [pc=0000039464A55451](this=0x037824a004b1 ,0x017863480119 <Very long string[1502653]>) 2: decodedSourcemap(aka decodedSourcemap) [000002AD02F8A979] [E:\vite-template\node_modules_rollup<EMAIL_ADDRESS>FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory 1: 00007FF696CD180F napi_wrap+119407 2: 00007FF696C787E6 v8::internal::OrderedHashTablev8::internal::OrderedHashSet,1::NextTableOffset+38102 3: 00007FF696C795E6 node::OnFatalError+438 4: 00007FF6974B5A6E v8::Isolate::ReportExternalAllocationLimitReached+94 5: 00007FF69749DC21 v8::SharedArrayBuffer::Externalize+833 6: 00007FF69734F3FC v8::internal::Heap::EphemeronKeyWriteBarrierFromCode+1436 7: 00007FF69735A640 v8::internal::Heap::ProtectUnprotectedMemoryChunks+1312 8: 00007FF697357154 v8::internal::Heap::PageFlagsAreConsistent+3204 9: 00007FF69734C953 v8::internal::Heap::CollectGarbage+1283 10: 00007FF69734AFC4 v8::internal::Heap::AddRetainedMap+2500 11: 00007FF69736C30D v8::internal::Factory::NewFillerObject+61 12: 00007FF6970CF76F v8::internal::interpreter::JumpTableTargetOffsets::iterator::operator=+1295 13: 00007FF69790ABBD v8::internal::SetupIsolateDelegate::SetupHeap+546925 14:<PHONE_NUMBER>A55451

修改vite构建脚本：
"scripts": {
"dev": "vite",
"build": "cross-env NODE_OPTIONS=--max_old_space_size=10240 vite build",
"preview": "vite preview"
}

"scripts": {
"dev": "vite",
"build": "cross-env NODE_OPTIONS=--max_old_space_size=10240 vite build",
"preview": "vite preview"
}
加大node内存

An curious discovery we've made- having encountered this issue, we were able to mitigate somewhat by chunking our bundle. This resolved the issue for us (allowing us to run on a much lower memory allocation). However, when we run vite build --mode custom-mode we run back into the heap full error.
It seems that setting a build mode other than production is affecting the ease of surfacing this particular error

Keeping NODE_OPTIONS=--max-old-space-size=8192 in my build script (package.json) worked.

It does, if you have that amount of memory. In our case, this bug means that we are now paying for more expensive build servers. That's a work around, but IMO the priority of this bug (vite consuming an insane amount of memory) should be quite high.

In my opinion "workaround" tags should be removed. We face this issue and can't use platforms like Vercel because our app consumes more than 8GB of RAM that they offer and it's not configureable.

I finally solved it by splitting the code into chunks 😅. I think that the reason it was happening was I had a very large chunk (my app is very big ~enterprise like codebase) It's size was 3mb/600kb gzip. Now, i have simply split them into different chunks by using splitVendorChunkPlugin
With this, we do not need to use the ugly --max-old-space-size=8192 NODE_OPTION anymore.
P.S: The issue is coming from rollup itself. As mentioned here https://rollupjs.org/guide/en/#error-javascript-heap-out-of-memory

then please provide a github repository or a reproduction via vite.new so it will be easier for us to look through

@Niputi  you can try my repo, things break after Glob Import is used. About 8m files are imported.
the commit that breaks CI https://github.com/Zzzen/pyright-ast-viewer/commit/c46fec7d1f21f9c28216c8a183dd1bcaa6ce7103
CI status https://github.com/Zzzen/pyright-ast-viewer/runs/7094218685?check_suite_focus=true

I've also been affected by this issue, and my project isn't even that big:
dist/assets/favicon.17e50649.svg   1.49 KiB
dist/index.html                    0.60 KiB
dist/assets/index.cc3a812a.js      22.91 KiB / gzip: 8.16 KiB
dist/assets/vendor.3fca7309.css    75.80 KiB / gzip: 9.82 KiB
dist/assets/index.41aec47a.css     311.17 KiB / gzip: 42.48 KiB
dist/assets/vendor.cdabcb6a.js     863.05 KiB / gzip: 245.12 KiB

Using splitVendorPlugin did not help, neither did NODE_OPTIONS=--max-old-space-size. Only thing that helps is adding more RAM to the system for the build...

For me it was the legacyBuild plugin that was making the build excessively long. From 30min -> 30seconds.

updeted vue-tsc

@guguji5 把sourcemap关掉了之后尝试了一下，还是一样的

有没有可能是vue-tsc的版本低导致的问题

@guguji5 把sourcemap关掉了之后尝试了一下，还是一样的

有没有可能是vue-tsc的版本低导致的问题

https://github.com/n9e/fe-v5/blob/master/package.json 我似乎没有用vue-tsc，是一个react项目

@guguji5 把sourcemap关掉了之后尝试了一下，还是一样的

有没有可能是vue-tsc的版本低导致的问题

https://github.com/n9e/fe-v5/blob/master/package.json 我似乎没有用vue-tsc，是一个react项目
我回复@guohui666 的vite+ vue3+ts问题， 不小心@了你，不好意思。

Have the same issue. Limited the memory by node --max_old_space_size= 7168 node_modules/.bin/vite --config config/vite.config.ts build. However, the CircleCI memory usage is far from even 50%,

It's not a pure vite project but the example repo I provided earlier in this thread provides a pretty simple reproduction of the issue from svelte kit.
Looks like all you need to do to reproduce it reliably is inflate the amount of files that need to be transformed. @benmccann did some debugging and suggested it may be an upstream issue from rollup.
Maybe someone could follow the same concept and create a vite project which can reproduce the issue in a similar way.

This is very frustrating. I'm getting the same error. If you are intended to use a 3GB RAM resource from AWS codebuild just stop wasting your time and forget this using vite idea.

Quite a funny one. Circle CI shows that the build is using too much CPU, not memory

I had something like this with webpack and it was with minifying. The Terser plugin can't read the number of CPUs of the running machine and it uses more CPUs than it's available. So the solution was to manually pass parallel option with the value of the number of CPUs available.
When I tried to get the number of CPUs in the circleci machine I got 36. However, it, actually, was 4 CPU Linux machine.

Can we should resolve this question?

Although I don't have a direct solution, I can confirm the following:

Sourcemaps are a major source for the problem.  Memory spiking in our builds went from 7GB to 2GB when disabling sourcemaps.
Code splitting via dynamic imports helped resolve the issue.  This is, of course, not always possible.
rollup-plugin-visualizer helped me decide the most profitable opportunities for code splitting.  It helped illustrate which modules were the largest that had the least number of touchpoints.

Utilizing manualChunks might help if you can manage it, although I haven't tested this yet.

I'm experiencing this on Github Actions:
vite v3.0.2 building for production...
transforming...
✓ [17](https://github.com/.../runs/7422089543?check_suite_focus=true#step:6:18)431 modules transformed.
<--- Last few GCs --->
[2335:0x663e6c0]    90499 ms: Mark-sweep 2006.9 (2087.3) -> 1994.2 (2089.5) MB, [18](https://github.com/.../runs/7422089543?check_suite_focus=true#step:6:19)16.9 / 0.0 ms  (average mu = 0.702, current mu = 0.264) allocation failure scavenge might not succeed
[2335:0x663e6c0]    92710 ms: Mark-sweep 2011.6 (2090.3) -> 2003.1 (2100.6) MB, 2120.1 / 0.0 ms  (average mu = 0.517, current mu = 0.041) allocation failure scavenge might not succeed
<--- JS stacktrace --->
FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
 1: 0xb0a860 node::Abort() [node]
 2: 0xa1c[19](https://github.com/.../runs/7422089543?check_suite_focus=true#step:6:20)3 node::FatalError(char const*, char const*) [node]
 3: 0xcf9a6e v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [node]
 4: 0xcf9de7 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [node]
 5: 0xeb1685  [node]
 6: 0xec1[34](https://github.com/.../runs/7422089543?check_suite_focus=true#step:6:35)d v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [node]
 7: 0xec404e v8::internal::Heap::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node]
 8: 0xe8558a v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationType, v8::internal::AllocationOrigin) [node]
 9: 0x11fe2d6 v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [node]
10: 0x15f2d39  [node]
Aborted (core dumped)

I found that removing the many dedupe entries I had in vite.config.js worked around out of memory on build, so seems like those may take up an inordinate amount of memory.
I replaced them with pnpmfile.cjs redirects, which can also be done with simpler pnpm aliases in cases.

I managed to fix this issue. No 'node' workarounds really helped me.

I disabled some sourcemaps for building

// vite.config.ts

const plugins = [
  react(),
  svgr({
    exportAsDefault: true,
  }),
  shimReactPdf(),
  friendlyTypeImports(),
  splitVendorChunkPlugin(),
];

if (process.argv.includes('--visualize')) {
  plugins.push(
    visualizer({
      title: 'Vite Visualizer',
      filename: './stats.html',
    }),
  );
}

// https://vitejs.dev/config/
export default defineConfig({
  plugins,
  publicDir: paths.publicFiles,
  root: paths.root,
  envDir: paths.root,
  build: {
    sourcemap: false,
    commonjsOptions: {
      sourceMap: false,
    },
    minify: true,
    rollupOptions: {
      output: {
        manualChunks: {
          editor: ['jodit'],
          reactPdf: ['react-pdf'],
          recharts: ['recharts'],
        },
      },
    },
  },
});

I added lazy loading for a lot of components by route

const BlogPage = React.lazy(() => import('../pages/blog'));
const AboutPage = React.lazy(() => import('./pages/about'));
const ApiPage = React.lazy(() => import('./pages/api'));

const MainRoute = () => {
  return (
      <Switch>
        <Route path={paths.blog} component={BlogPage} />
        <Route exact path={paths.about} component={AboutPage} />
        <Route exact path={paths.api} component={ApiPage} />
      </Switch>
  );
};

export default QuestionBoxesRoute;

Something more specific, but I replaced the 'react-file-viewer' lib with some custom solution

I was building the app on ubuntu-linux (via github action runners). I got it solved by enabling the swap space on linux.
    - name: Set Swap Space
        if: matrix.os == 'ubuntu-latest'
        uses: pierotofy/set-swap-space@master
        with:
          swap-size-gb: 10

Disabling the sourcemaps helped me get the build process working...

Disabling the sourcemaps didn't help me.

For those using plugin-legacy, a common way to bring down build time is to specify its polyfills and modernPolyfills option manually as an array. This is because true would scan/parse the entire code for polyfill auto-detection which takes longer if you have a large bundle size. A good starting point for the arrays can be retrieved via DEBUG="vite:legacy" npm run build which will print out the auto-detected polyfills into the console.

Not sure it this helps, but setting rollupOptions.maxParallelFileReads to a lower value like 5 slow the spike in memory usage enough to let the build run successfully in my case.

Not sure if this helps, but setting rollupOptions.maxParallelFileReads to a lower value like 5 slow the spike in memory usage enough to let the build run successfully in my case.
Before that, my build always failed/being killed in my self-hosted Drone CI with spike in memory usage to 5-6GB and rapidly consume the swap space when the memory is full. However, I can always build successfully on my local machine (Macbook).

Unfortunately this did not work on my reproduction repo
https://github.com/Axeldeblen/realworld-big-build/pull/2

Is there at least a way to tell why it consumes all that RAM? Maybe a trace or something? I'm facing this issue on a new project with element-plus package and only three pages :\

Started getting this error only recently, after switching to version 3 and using
optimizeDeps: {
  disabled: false
}

In order to get ESBuild to optimize our dependencies on build, as opposed to rollup.
Its a real blocker as Cloudflare is struggling to build our app now in the pipeline.

setting rollupOptions.maxParallelFileReads to a lower value like 5

Thank you, this is really helpful!
For ones who did not get how: in vite.config.js
export default defineConfig({
...
  build: {
    rollupOptions: {
      maxParallelFileReads: 5
   ...
    }
  }
...
+

node --max_old_space_size=16384 ./node_modules/vite/bin/vite.js
Thank you, this helped.
For ones who did not get, in packages.json instead of this:

"build": "vite build",

use this:
"build": "node --max_old_space_size=16384 ./node_modules/vite/bin/vite.js build"

Same here. Can't deploy to production. Deadline is today lol.

Same here. Can't deploy to production. Deadline is today lol.

Do you disable the sourcemap?

Same here. Can't deploy to production. Deadline is today lol.

Do you disable the sourcemap?

I disabled sourcemap but it didn't work, our js bundle is about 9M+ and sourcemap is about 30+M

Same here. Can't deploy to production. Deadline is today lol.

Do you disable the sourcemap?

Yes. Had to put that node old memory command with 4GB swap to deploy. It took 7 minutes on<EMAIL_ADDRESS>I experienced the same when using big JS frameworks.
At least for me, Vite/Rollup should have an option to run with limited memory constraints, or optimize packages separately so the whole build doesn't stall and leaves the developer wondering why he didn't stuck with Webpack.

In our case PostCSS was causing the issue, we stopped using it and everything was fine.

@creativiii Sometimes you can't because your external import is what takes all the memory (in my case was Monaco Editor).

Completely clueless as to what to do tbh. Started a job at a new place, they had broken webpack setup.
Figured will move to Vite, after configuring and fixing million things now can't even build the project....
Tried everything suggested in this thread, nothing worked... Really not sure what is the next step.
I reached out for Vite because it is a "zero setup" kinda tool since I am no expert in build tools. But alas :(
Does anyone know what would be my next step?
My vite config below:
`import { defineConfig } from "vite";
import react from "@vitejs/plugin-react";
import postcssPresetEnv from "postcss-preset-env";
import mkcert from "vite-plugin-mkcert";
import shimReactPdf from "vite-plugin-shim-react-pdf";
import vitePluginImp from "vite-plugin-imp";
import { splitVendorChunkPlugin } from "vite";
export default defineConfig({
build: {
sourcemap: false,
},
resolve: {
alias: [{ find: /^~/, replacement: "" }],
},
// We had to use shimsReactPdf for Node shims that were needed by RSS module.
plugins: [
react(),
mkcert(),
shimReactPdf(),
vitePluginImp(),
splitVendorChunkPlugin(),
],
server: {
port: 3000,
https: true,
},
css: {
postcss: {
plugins: [
postcssPresetEnv({
browsers: [">0.25%", "not ie 11", "not op_mini all"],
}),
],
},
preprocessorOptions: {
less: {
modifyVars: {
"@primary-color": "#ffcc33",
"@layout-header-height": "54px",
"@layout-header-background": "#4e8c98",
"@layout-header-padding": "0 20px",
"@border-radius-base": "4px", // major border radius
"@layout-footer-padding": "5px",
"@layout-footer-background": "#4e8c98",
"@menu-item-vertical-margin": "0px",
"@menu-item-boundary-margin": "0px",
"@breadcrumb-link-color": "#fff",
"@breadcrumb-link-color-hover": "@primary-color",
"@breadcrumb-separator-color": "#fff",
"@breadcrumb-last-item-color": "@primary-color",
"@input-addon-bg": "@layout-header-background",
"@info-color": "#1890ff",
"@text-selection-bg": "@info-color",
},
javascriptEnabled: true,
},
},
},
});
`

@ievgenk I agree- this is actually a MAJOR issue with Vite at the moment, but seems to not have the right priority with the Vite devs.
The only way around it for us was to downgrade to version 2 for now, which is rather unfortunate and wasted a lot of time because we had moved everything over to version 3 only to be met with this major roadblock, just like yourself.

The only way around it for us was to downgrade to version 2 for now, which is rather unfortunate and wasted a lot of time because we had moved everything over to version 3 only to be met with this major roadblock, just like yourself.

@lostpebble i'm curious to which exact version you downgraded vite, and what rollup version it is using?

@lostpebble i'm curious to which exact version you downgraded vite, and what rollup version are you using then?

We're using 2.9.15 (latest version 2) right now. It appears to be using rollup version 2.77.3.

Unfortunately, we get the same issue :( Liked for more visibility

@ievgenk I agree- this is actually a MAJOR issue with Vite at the moment, but seems to not have the right priority with the Vite devs.

Feel free to send a PR to fix this. We don't really have a priority on issues to fix as Vite is a community project. We're happy to help discuss some internal code in https://chat.vitejs.dev though if you're debugging into Vite code.

I've put p4 on this. I didn't thought the comment was about the labels, but I think it make sense to bump it up given the number of responses so far. Still with the help wanted label, it would be great if someone could help look into this though.

I was trying to dig into this and find the root of the issue, but to no avail... On the one hand, there is rollup which holds the whole projects source in memory to allow it to chunk (afaik) properly which by itself requires quite some memory, but then there is this step rendering chunks (...) during which memory usage (for me) suddenly triples for a short moment, but this only seems to happen when sourcemaps are enabled.
Got lost eventually and had to stop, but happy about findings from others... I was jumping through the src of vite, rollup and also https://github.com/Rich-Harris/magic-string which is used internally stuff like sourcemaps (I looked into it because apparently there have been leak issues with it in the past)
The magic string issue on rollup seems to match with my 3x memory usage observation: https://github.com/rollup/plugins/issues/1064 -> https://github.com/Rich-Harris/magic-string/issues/195

@flipace I don't think you need to bump the CI resources as node's memory limit can surpass the physical memory, node will read/write to the disk if needed.

same for me,
as soon as I've added 'google-ads-api' import in my electron/main, building became very slow and started failing with "Reached heap limit Allocation failed - JavaScript heap out of memory" :(

in my case we have a fairly large react app and 2 things helped:

Manual chunks for large libraries (link)
Path imports for any Material ui @mui assets (link)

On a related note, since we're already doing a bunch of the workarounds here - is there a way to disable source maps for some chunks in Vite/rollup? I only found an all or nothing flag, and trying to hook into renderChunk and returning { code: code, map: null } for the relevant chunk still produces a source map.
What I'm trying to achieve is to remove source maps from large third party libraries (e.g. monaco-editor), for which I don't care about the source maps, and yet they're huge and give us the OOM issues in most runs.

You can try to remove terser
minify: false,
# or
minify: 'esbuild',

Here has same error. I use pnpm and pnpm workspace. This project may has a circular reference.

Same issue here:
✓ 191 modules transformed.

<--- Last few GCs --->

[79509:0x5e31c10]   186542 ms: Mark-sweep (reduce) 759.6 (779.3) -> 758.4 (779.3) MB, 20500.1 / 0.8 ms  (average mu = 0.181, current mu = 0.206) allocation failure scavenge might not succeed
[79509:0x5e31c10]   221591 ms: Mark-sweep (reduce) 759.9 (779.8) -> 758.7 (779.8) MB, 32711.0 / 0.6 ms  (average mu = 0.118, current mu = 0.067) allocation failure scavenge might not succeed

<--- JS stacktrace --->

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0xb02960 node::Abort() [node]
 2: 0xa18149 node::FatalError(char const*, char const*) [node]
 3: 0xcdd22e v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [node]
 4: 0xcdd5a7 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [node]

Here has same error. I use pnpm and pnpm workspace. This project may has a circular reference.

I reslove this error by turn off sourcemap, but sourcemap is nesscuary for me to debug on production environment

Facing the same error in CI (GitHub Actions). The only change I did to my Vite config recently after which this error started showing up was to introduce `build.assetsInlineLimit: 0 as a workaround for https://github.com/vitejs/vite/issues/9879#issuecomment-1229468552

For us this seems to be caused by sourcemap generation. With sourcemaps enabled the peak memory usage, as shown by /usr/bin/time -v, is about 3.4gb. Disabling sourcemaps cuts that to about 1.3gb.

I'm experiencing this problem even with sourcemap generation disabled. Possibly related to Vite trying to transform ~200.000 files (from `node_modules).

npm run build command executes successfully on my local dev laptop with 16Gb ram, but when I try to execute the same command on my Linux server with 4Gb ram, the process simply gets killed.

Hi, let me tell you a story of me encountered this issue twice for the last 1 year and thankfully those cases has been solved, I hope this is helpful.
First encounter
I forgot the exact detail about the first one since it was a long time ago & hundreds of commits ago, so it's hard for me to track and check it again, but it was memory issue as well. But the point is it wasn't using Vite, it's simply CRA with CRACO. So I think that's an interesting info.
I've tried the --max-old-space-size=xxxx workaround and set the threshold to 8Gb, sometimes it works sometimes it's not, and it was happening in the middle of our migration from Material UI v4 to v5, after the migration completed which also consist of cleaning / changing some dependencies that doesn't support v5, somehow the error goes away forever (or so I thought).
Second encounter
It happened recently with the same project but it's already using Vite version 2, The logs always stop at: ✓ xxxx modules transformed and then throw error JavaScript heap out of memory. Looking into the memory usage it's always stable but after that ✓ xxxx modules transformed log is shown, mem usage sky rocket like crazy. It works fine on my machine because it has 32Gb ram, but it's failing on our CI.
Having the --max-old-space-size=xxxx will only help Node to keep mem usage below xxxx if you're lucky that will works, but if you're unlucky (like me) it will always asking for mem usage above that threshold which in that case will make the error JavaScript heap out of memory happening again. I've tried to update to Vite 3 but the same error still occurs.
And all of this 2nd encounter happen after one commit that added a package called cities.json. Turns out, that package has one relatively large json file (I remember it's about 6Mb). And we import it directly into React app! 6Mb ... my god.
So I guessed, probably this is happening at the minifying / uglifying / sourcemaping phase and with that file size I think it's capable to eat a lot of memory at one go. So I start to copy the cities.json and strip down the data, because there are some data that we don't use and I was able to reduce the file size into 1.6Mb it's still huge but much much better than the original.
And I changed the import to use dynamic import. Not because concern of the file size but (I assume) the minifier will have an easier task to parse that 1.6Mb separately (I assume separated bundle has an effect the way minifier eat the mem usage).
And trying my luck to push it and test on CI ... it works.
Conclusion
I become confident that the culprit is in minifying / uglifying / sourcemaping phase which has nothing to do with Vite (or is it?). I'm not familiar with Vite or CRA internal but I read both of them are using terser for the minifier, so probably we should look at terser?
My suggestion for people that are still encountering this issue, check your dependencies and the output size of your bundle, try to reduce it as much as you can and try to disable sourcemap on CI build as other have said. If this issue is happening to you probably it's an indicator you're doing something wrong on your codebase, perhaps it is too large or too complex.
I know very little to nothing about all of these thing, sorry for the long text, and thanks for this great tools! peace :v:

Hi, let me tell you a story of me encountered this issue twice for the last 1 year and thankfully those cases has been solved, I hope this is helpful.
First encounter
I forgot the exact detail about the first one since it was a long time ago & hundreds of commits ago, so it's hard for me to track and check it again, but it was memory issue as well. But the point is it wasn't using Vite, it's simply CRA with CRACO. So I think that's an interesting info.
I've tried the --max-old-space-size=xxxx workaround and set the threshold to 8Gb, sometimes it works sometimes it's not, and it was happening in the middle of our migration from Material UI v4 to v5, after the migration completed which also consist of cleaning / changing some dependencies that doesn't support v5, somehow the error goes away forever (or so I thought).
Second encounter
It happened recently with the same project but it's already using Vite version 2, The logs always stop at: ✓ xxxx modules transformed and then throw error JavaScript heap out of memory. Looking into the memory usage it's always stable but after that ✓ xxxx modules transformed log is shown, mem usage sky rocket like crazy. It works fine on my machine because it has 32Gb ram, but it's failing on our CI.
Having the --max-old-space-size=xxxx will only help Node to keep mem usage below xxxx if you're lucky that will works, but if you're unlucky (like me) it will always asking for mem usage above that threshold which in that case will make the error JavaScript heap out of memory happening again. I've tried to update to Vite 3 but the same error still occurs.
And all of this 2nd encounter happen after one commit that added a package called cities.json. Turns out, that package has one relatively large json file (I remember it's about 6Mb). And we import it directly into React app! 6Mb ... my god.
So I guessed, probably this is happening at the minifying / uglifying / sourcemaping phase and with that file size I think it's capable to eat a lot of memory at one go. So I start to copy the cities.json and strip down the data, because there are some data that we don't use and I was able to reduce the file size into 1.6Mb it's still huge but much much better than the original.
And I changed the import to use dynamic import. Not because concern of the file size but (I assume) the minifier will have an easier task to parse that 1.6Mb separately (I assume separated bundle has an effect the way minifier eat the mem usage).
And trying my luck to push it and test on CI ... it works.
Conclusion
I become confident that the culprit is in minifying / uglifying / sourcemaping phase which has nothing to do with Vite (or is it?). I'm not familiar with Vite or CRA internal but I read both of them are using terser for the minifier, so probably we should look at terser?
My suggestion for people that are still encountering this issue, check your dependencies and the output size of your bundle, try to reduce it as much as you can and try to disable sourcemap on CI build as other have said. If this issue is happening to you probably it's an indicator you're doing something wrong on your codebase, perhaps it is too large or too complex.
I know very little to nothing about all of these thing, sorry for the long text, and thanks for this great tools! peace ✌

I just migrated from Webpack 4 (CRA v4) and I did not face this topic's issue until I migrated over to Vite 3+. So I believe it's technically a Vite issue.
I do use MUI v4 right now though, and I started seeing this myself when I enabled source maps.

I experienced this while using the Storybook vite-builder, and was able to workaround it by disabling sourcemaps in my Vite config. After I did that my storybook build succeeded without the out of memory error.

Is there a way to tell vite to skip optimization of a specific package such as "@fontsource/noto-sans-jp"? These packages are causing issue in my case.

Unfortunately, I use Sentry, and I believe source maps are needed for Sentry to help debug properly

I would have to agree with this comment.
Sadly, disabling sourcemap cannot be enough solution.

I had the same issue, so I broke the bundle in smaller chunks https://vitejs.dev/guide/build.html#chunking-strategy and I was able to rebuild with sourcemaps.

I had the same issue, so I broke the bundle in smaller chunks https://vitejs.dev/guide/build.html#chunking-strategy and I was able to rebuild with sourcemaps.

yeah, use splitVendorChunkPlugin by default option reslove my issue, and I can use sourcemap again~~Thank you

So I hit this, out of the blue. Builds were taking a while, but it's a biggish SvelteKit project and I added a couple more things and ... nope, no build. I got up to NODE_OPTIONS=--max-old-space-size=32768 before giving up.
Finally figured out the pieces that were blocking it for me though. I'm using various @jsquash/ packages and including both @jsquash/avif and @jsquash/oxipng killed it. But in both cases it was the scripts todo with multi-threaded WASM.
Removing those parts and ... it worked!
Example of the change, in<EMAIL_ADDRESS>    if (!wasmReady) {
        const hasHardwareConcurrency = ((_a = globalThis.navigator) === null || _a === void 0 ? void 0 : _a.hardwareConcurrency) > 1;
        wasmReady = hasHardwareConcurrency ? threads().then((hasThreads) => hasThreads ? initMT(moduleOrPath) : initST(moduleOrPath)) : initST(moduleOrPath);
        wasmReady = initST(moduleOrPath)
    }

This is blocking our migration from vite 2.5.6 to 3.2.2. The build used to run fine on a small instance on CircleCI and now it fails even on a large one.
yarn run v1.22.18
$ vite build --mode cypress
[log] vite v3.2.2 building for cypress...
[log] transforming...
[warn] Use of eval is strongly discouraged, as it poses security risks and may cause issues with minification
[warn] Use of eval is strongly discouraged, as it poses security risks and may cause issues with minification
[warn] Use of eval is strongly discouraged, as it poses security risks and may cause issues with minification
[log] ✓ 4559 modules transformed.
[log] rendering chunks...

<--- Last few GCs --->

[701:0x55e97b0]    81174 ms: Mark-sweep (reduce) 2026.2 (2075.0) -> 2025.8 (2075.8) MB, 883.2 / 0.0 ms  (+ 28.5 ms in 6 steps since start of marking, biggest step 6.3 ms, walltime since start of marking 922 ms) (average mu = 0.727, current mu = 0.202) all[701:0x55e97b0]    82166 ms: Mark-sweep (reduce) 2032.8 (2081.6) -> 2031.2 (2081.2) MB, 980.6 / 0.0 ms  (average mu = 0.563, current mu = 0.012) allocation failure scavenge might not succeed

<--- JS stacktrace --->

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
 1: 0xb09c10 node::Abort() [/usr/local/bin/node]
 2: 0xa1c193 node::FatalError(char const*, char const*) [/usr/local/bin/node]
 3: 0xcf8dbe v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/usr/local/bin/node]
 4: 0xcf9137 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/usr/local/bin/node]
 5: 0xeb09d5  [/usr/local/bin/node]
 6: 0xec069d v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/usr/local/bin/node]
 7: 0xec339e v8::internal::Heap::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/usr/local/bin/node]
 8: 0xe848da v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationType, v8::internal::AllocationOrigin) [/usr/local/bin/node]
 9: 0x11fd626 v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [/usr/local/bin/node]
10: 0x15f2099  [/usr/local/bin/node]
Aborted (core dumped)
error Command failed with exit code 134.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Exited with code exit status 134

What's weird is that it doesn't seem to be using all RAM in the executor:

I had the same issue, so I broke the bundle in smaller chunks https://vitejs.dev/guide/build.html#chunking-strategy and I was able to rebuild with sourcemaps.

This resolved the issue for me as well.

This is blocking our migration from vite 2.5.6 to 3.2.2. The build used to run fine on a small instance on CircleCI and now it fails even on a large one.
yarn run v1.22.18
$ vite build --mode cypress
[log] vite v3.2.2 building for cypress...
[log] transforming...
[warn] Use of eval is strongly discouraged, as it poses security risks and may cause issues with minification
[warn] Use of eval is strongly discouraged, as it poses security risks and may cause issues with minification
[warn] Use of eval is strongly discouraged, as it poses security risks and may cause issues with minification
[log] ✓ 4559 modules transformed.
[log] rendering chunks...

<--- Last few GCs --->

[701:0x55e97b0]    81174 ms: Mark-sweep (reduce) 2026.2 (2075.0) -> 2025.8 (2075.8) MB, 883.2 / 0.0 ms  (+ 28.5 ms in 6 steps since start of marking, biggest step 6.3 ms, walltime since start of marking 922 ms) (average mu = 0.727, current mu = 0.202) all[701:0x55e97b0]    82166 ms: Mark-sweep (reduce) 2032.8 (2081.6) -> 2031.2 (2081.2) MB, 980.6 / 0.0 ms  (average mu = 0.563, current mu = 0.012) allocation failure scavenge might not succeed

<--- JS stacktrace --->

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
 1: 0xb09c10 node::Abort() [/usr/local/bin/node]
 2: 0xa1c193 node::FatalError(char const*, char const*) [/usr/local/bin/node]
 3: 0xcf8dbe v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/usr/local/bin/node]
 4: 0xcf9137 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/usr/local/bin/node]
 5: 0xeb09d5  [/usr/local/bin/node]
 6: 0xec069d v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/usr/local/bin/node]
 7: 0xec339e v8::internal::Heap::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/usr/local/bin/node]
 8: 0xe848da v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationType, v8::internal::AllocationOrigin) [/usr/local/bin/node]
 9: 0x11fd626 v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [/usr/local/bin/node]
10: 0x15f2099  [/usr/local/bin/node]
Aborted (core dumped)
error Command failed with exit code 134.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Exited with code exit status 134

What's weird is that it doesn't seem to be using all RAM in the executor:

Have to tell node to use more memory, eg. NODE_OPTIONS=--max-old-space-size= 7168 vite build ...

Thanks, it ended up working with manualChunks

This is blocking our migration from vite 2.5.6 to 3.2.2. The build used to run fine on a small instance on CircleCI and now it fails even on a large one.
yarn run v1.22.18
$ vite build --mode cypress
[log] vite v3.2.2 building for cypress...
[log] transforming...
[warn] Use of eval is strongly discouraged, as it poses security risks and may cause issues with minification
[warn] Use of eval is strongly discouraged, as it poses security risks and may cause issues with minification
[warn] Use of eval is strongly discouraged, as it poses security risks and may cause issues with minification
[log] ✓ 4559 modules transformed.
[log] rendering chunks...

<--- Last few GCs --->

[701:0x55e97b0]    81174 ms: Mark-sweep (reduce) 2026.2 (2075.0) -> 2025.8 (2075.8) MB, 883.2 / 0.0 ms  (+ 28.5 ms in 6 steps since start of marking, biggest step 6.3 ms, walltime since start of marking 922 ms) (average mu = 0.727, current mu = 0.202) all[701:0x55e97b0]    82166 ms: Mark-sweep (reduce) 2032.8 (2081.6) -> 2031.2 (2081.2) MB, 980.6 / 0.0 ms  (average mu = 0.563, current mu = 0.012) allocation failure scavenge might not succeed

<--- JS stacktrace --->

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
 1: 0xb09c10 node::Abort() [/usr/local/bin/node]
 2: 0xa1c193 node::FatalError(char const*, char const*) [/usr/local/bin/node]
 3: 0xcf8dbe v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/usr/local/bin/node]
 4: 0xcf9137 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/usr/local/bin/node]
 5: 0xeb09d5  [/usr/local/bin/node]
 6: 0xec069d v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/usr/local/bin/node]
 7: 0xec339e v8::internal::Heap::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/usr/local/bin/node]
 8: 0xe848da v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationType, v8::internal::AllocationOrigin) [/usr/local/bin/node]
 9: 0x11fd626 v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [/usr/local/bin/node]
10: 0x15f2099  [/usr/local/bin/node]
Aborted (core dumped)
error Command failed with exit code 134.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Exited with code exit status 134

What's weird is that it doesn't seem to be using all RAM in the executor:

For what it's worth I've been debugging this on our project for a while as it has been blocking us from upgrading sveltekit for months now.
I assumed that when it crashed in the vercel/netlify builds (8gb build memory) that it was because it was building in a different environment (linux) and that perhaps it was a linux version of a package like esbuild that might be causing the issue.
I finally got Netlify builds working locally to build the same project with their environment and I can confirm that the linux builds seem to use the same amount of memory as when it builds on my machine (mac).
For context our build seems to peak at around 3.5 GB on both environments it fails in the netlify linux docker container but works locally. I can see that the CPU is spiking pretty hard on the Docker container with ~+400% usasge.
Hopefully that helps narrow down the issue somewhat for anyone else who is trying to debug it.

For me sourcemap was the culprit:
build: {
  sourcemap: process.env.NODE_ENV !== 'production', // Seems to cause JavaScript heap out of memory errors on build
},

For me, this started happening when I tried turning on forceBuildInstrument to get code coverage working. This issue is blocking my team from implementing code coverage for any instance of our app running outside dev mode (serve|build). Instrumentation is working for npm run start (dev) mode though.
will update this comment with more information as I research/troubleshoot

I heard there was a bounty on this bug, maybe someone can post an opencollective or similar link.

Are there any actual fixes for this issue? I started getting this error today out of nowhere.
Using the --max_old_space_size=16384 works, but my assets take almost 5 minutes to build?
Everything was running so smoothly until today!

I spent some time analyzing the heap snapshot of https://github.com/stillgbx/vite-build-issue today (It's Vite 2 and Rollup 2 but the core issue should still apply). What I found is that most of Rollup's AST is being retained in the heap, likely through Rollup's module graph (?). The docs mentioned that it's used for side effects analysis, but I wonder if the entire AST is required for it, or if we could pre-compute and prune them.

--max-old-space-size is just workaround, it is not solution.
In my case, solution is turning off source map generation.
With source map building process takes 6GB of the RAM, but without - only 2 GB.

Any update on this? Turning off the sourcemaps works, but in my case I really need them on for debugging an error that is happening only on production.

For me also turning off sourcemaps doesn't work. The only thing that consistently works isn turning off minification.
I turned off sourcemaps like this in vite.config.ts:
  defineConfig({
    build: {
      sourcemap: false,
    }
  })

For anyone building their application inside a BitBucket pipeline, they offer a size option for increasing available pipeline memory to 8GB (default is 4GB). This was enough to work around the problem in my scenario.

Small update to the example repo.
I've create a new version of the sveltekit realworld app to check if vite 4 still suffers the same issue. Unfortunately looks like this issue still persists. The inflated build size still OOMs and fails.
build fails with 2000 folders.
build succeeds with 1000 folders.

I've submitted https://github.com/rollup/rollup/pull/4762 which should help slightly. The memory still scales proportionately to the number of files, but it should consume less memory per file now.
You can try it out with:
// vite.config.js
export default {
  build: {
    rollupOptions: {
      cache: false
    }
  }
}

and override rollup (pnpm):
"pnpm": {
  "overrides": {
    "rollup": "github:bluwy/rollup#ast-lru"
  }
}

npm overrides should also work by removing the pnpm key and set overrides key directly in package.json.

and override rollup in package.json

It was merged and released 🎉
https://github.com/rollup/rollup/pull/4762#issuecomment-1363635539

The above rollup patch didn't help in my case (AWS instance with 2GB of RAM)
I did a workaround by adding a 4GB swap file on the EC2 instance. That kept me from having to pay for a more expensive instance just because of this issue.
https://aws.amazon.com/premiumsupport/knowledge-center/ec2-memory-swap-file/

Following fixed memory issue on 4 GB Ram with no swap
build: {     sourcemap: false,     rollupOptions: {       cache: false,     },   },

Maybe it can help in some situation, we faced a 8GB+ memory while stuck on transforming files on our side (Vue Project with some global components, scsss files and tailwind, we are using import.meta.glob in the app too) putting in build config
rollupOptions: {
   maxParallelFileOps: 2,
},

Help to reduce the situation in our case, default is 20, I we let him out put higher it increase the memory using. We suspect something  is wrong on a binary (maybe sass ?) and the most of files transform at a time the most we stuck and memory increase.

@MatthD - Ty for mentioning that. I was able to use that setting and it helped in my case too. I also used
My current vite build config that allowed me to use sourcemaps and get around this issue:
    build: {
      rollupOptions: {
        maxParallelFileOps: 2,
        output: {
          sourcemap: true,
          manualChunks: (id) => {
           if (id.includes('node_modules')) {
              return 'vendor';
            }
          },
        },
      },
    },

I had this issue while I was developing a local Laravel package that was symlinked into my vendor/ directory.
I use Vite with a Inertia.js and Vue3 frontend.
When I removed this local installation (symlink) of my package and installed the normal published version on packagist, this problem went away.
I had tried every solution in this thread to no avail.
This is unfortunately not a long term solution because when I when I need to develop my next package this problem will resurface.
Vite Version: 4.0.4

I am facing the issue:
rendering chunks (1)...Sourcemap is likely to be incorrect: a plugin (vite:build-import-analysis) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Below is the source map file content:
{"version":3,"file":"index.7aacfb63.js","sources":[],"sourcesContent":[],"names":[],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;"}

I am facing same issue as well... any solution?

I wonder why sourcemapIgnoreList isn't supported? https://rollupjs.org/configuration-options/#output-sourcemapignorelist
Maybe this could help?

It's supported through build.rollupOptions. IIUC it doesn't help with the memory issue, it's only a hint for chrome to provide better sourcemap viewing experience.

I have the same issue on GH actions
✓ 3800 modules transformed.
rendering chunks...
<--- Last few GCs --->
[1935:0x5db1f80]    55091 ms: Mark-sweep (reduce) 2044.2 (2089.2) -> 2028.6 (2075.3) MB, 1424.6 / 0.0 ms  (+ 48.5 ms in 29 steps since start of marking, biggest step 20.8 ms, walltime since start of marking 1717 ms) (average mu = 0.633, current mu = 0.510[1935:0x5db1f80]    58248 ms: Mark-sweep (reduce) 2041.2 (2087.9) -> 2041.1 (2086.9) MB, 3141.8 / 0.0 ms  (average mu = 0.352, current mu = 0.005) allocation failure; scavenge might not succeed
<--- JS stacktrace --->
FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
 1: 0xb7b3f0 node::Abort() [node]
 2: 0xa8c89a  [node]
 3: 0xd631b0 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [node]
 4: 0xd63557 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [node]
 5: 0xf40c55  [node]
 6: 0xf53[13](https://github.com/am2222/nai-frontend/actions/runs/4289996165/jobs/7473561965#step:6:13)d v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [node]
 7: 0xf2d83e v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node]
 8: 0xf2ec07 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node]
 9: 0xf0f[15](https://github.com/am2222/nai-frontend/actions/runs/4289996165/jobs/7473561965#step:6:15)0 v8::internal::Factory::AllocateRaw(int, v8::internal::AllocationType, v8::internal::AllocationAlignment) [node]
10: 0xf06bc4 v8::internal::FactoryBase<v8::internal::Factory>::AllocateRawWithImmortalMap(int, v8::internal::AllocationType, v8::internal::Map, v8::internal::AllocationAlignment) [node]
11: 0xf08e78 v8::internal::FactoryBase<v8::internal::Factory>::NewRawOneByteString(int, v8::internal::AllocationType) [node]
12: 0x10491c9 v8::internal::JsonParser<unsigned short>::MakeString(v8::internal::JsonString const&, v8::internal::Handle<v8::internal::String>) [node]
13: 0x104aee6 v8::internal::JsonParser<unsigned short>::ParseJsonValue() [node]
14: 0x104b9cf v8::internal::JsonParser<unsigned short>::ParseJson() [node]
15: 0xde8d93 v8::internal::Builtin_JsonParse(int, unsigned long*, v8::internal::Isolate*) [node]

My build
  build: {
    target: browserslistToEsbuild(),
    rollupOptions: {
      maxParallelFileOps: 2,
      cache: false,
      output: {
        sourcemap: false,
        manualChunks: (id) => {
         if (id.includes('node_modules')) {
            return 'vendor';
          }
        },
      },
    }
  },

And here is my env
          NODE_OPTIONS: --max-old-space-size=32768

Perhaps counting the cpus helps?
import { cpus } from "os";
maxParallelFileOps: Math.max(1, cpus().length - 1),

@samelie I tried that and it didn't work.

I had this issue when I was building vite through a github action. As a temporary fix, you can add to NODE_OPTIONS the flag:
max-old-space-size
with a larger specification than the one it failed on (for me 'max-old-space-size=4096' did the trick).
For general information: the github lowest cost machines (ubunto-latest) reach 7GB RAM so the flag should be able to fix the issue for the node process / Vite that is the actual cause.
This can be done by creating a .npmrc file at the root of your project (where the package.json usually resides) and adding the following line in it:
max-old-space-size=4096
If you are not sure that the memory changed, you can check it by creating a script that runs the following:
`
import v8 from "v8";
console.table(v8.getHeapStatistics());
`
and running it as part of your github action steps after the installation phase
Hope that helps!

After comparing with other projects I realised compile options in tsconfig.json was the one causing my all the headaches with memory allocation issues

Can you elaborate on what compilerOptions did you changed to help with the memory allocation issue?

Any updates about this bug? I've got this issue too (in GH actions), but none of the methods above worked. This bug unreproducible on local machine, and GH logs don't say something about the reason of the problem.

Any updates about this bug? I've got this issue too (in GH actions), but none of the methods above worked. This bug unreproducible on local machine, and GH logs don't say something about the reason of the problem.

I got GH actions working by installing cross-env altering the NPM build script to the following
"build": "cross-env NODE_OPTIONS=--max-old-space-size=8192 vite build",

Thanks @EfstathiadisD for charting the course. Confirming this resolved all the problems.
import type { Plugin } from "vite";

interface SourcemapExclude {
    excludeNodeModules?: boolean;
}
export function sourcemapExclude(opts?: SourcemapExclude): Plugin {
    return {
        name: "sourcemap-exclude",
        transform(code: string, id: string) {
            if (opts?.excludeNodeModules && id.includes("node_modules")) {
                return {
                    code,
                    // https://github.com/rollup/rollup/blob/master/docs/plugin-development/index.md#source-code-transformations
                    map: { mappings: "" },
                };
            }
        },
    };
}

// USAGE

sourcemapExclude({ excludeNodeModules: true }),

I find a reason of problem in my case. It's import of elkjs library by the following way presented in their docs for typescript usage import ELK from 'elkjs/lib/elk.bundled' . But anyway no one solution doesn't work, also submitted by @EfstathiadisD and @samelie

In case it helps someone else, what finally worked for us:

Raising the memory limit to 3GB with NODE_OPTIONS=--max-old-space-size=3072
Raising the build agent memory limit to 4GB, since it didn't have memory swap enabled it would crash after exceeding 3GB limit with no clear error.

All the other various workarounds listed in the comments didn't resolve the issue.
Something that helped debug the issue was building the project in WSL, I couldn't reproduce the issue when running build locally on windows but could do so when building the project through wsl.

Any updates about this bug? I've got this issue too (in GH actions), but none of the methods above worked. This bug unreproducible on local machine, and GH logs don't say something about the reason of the problem.

I got GH actions working by installing cross-env and altering the NPM build script to the following
"build": "cross-env NODE_OPTIONS=--max-old-space-size=8192 vite build",

Thank your solution.

Any updates about this bug? I've got this issue too (in GH actions), but none of the methods above worked. This bug unreproducible on local machine, and GH logs don't say something about the reason of the problem.

I got GH actions working by installing cross-env and altering the NPM build script to the following

"build": "cross-env NODE_OPTIONS=--max-old-space-size=8192 vite build",

Thank your solution.

I am not saying your solution didn't work but tbh aside from real large applications (30,40+ Full Fledge Modules) you shouldn't need that much Heap Size. For my App that's unacceptable tbh.
Let me give you an example. We are running in machines in CI with 2Gb of Ram which means the setting you set for us should be approx. 1.5Gb or 1536 IINM..
We could update, we could increase it but it's like taking a Ferrari with a V12 to go to the grocery store 100m from your house.
Again if the problem you had was solved great, but no modern Web App besides very very very few should set the memory limit above 4Gb. Just my humble opinion.

Any updates about this bug? I've got this issue too (in GH actions), but none of the methods above worked. This bug unreproducible on local machine, and GH logs don't say something about the reason of the problem.

I got GH actions working by installing cross-env and altering the NPM build script to the following

"build": "cross-env NODE_OPTIONS=--max-old-space-size=8192 vite build",

Thank your solution.

I am not saying your solution didn't work but tbh aside from real large applications (30,40+ Full Fledge Modules) you shouldn't need that much Heap Size. For my App that's unacceptable tbh.

Let me give you an example. We are running in machines in CI with 2Gb of Ram which means the setting you set for us should be approx. 1.5Gb or 1536 IINM..

We could update, we could increase it but it's like taking a Ferrari with a V12 to go to the grocery store 100m from your house.

Again if the problem you had was solved great, but no modern Web App besides very very very few should set the memory limit above 4Gb. Just my humble opinion.

Hello from the real world!
If the Ferrari get's you to the grocery store when other forms of transport do not then I'll use the Ferrari.
The GitHub Action runners are 2 core VMs with 7GB of memory. Changing the heap size will not make these more powerful. Use of these machines is charged per minute so jobs running on them should be optimised with that in mind. Setting the heap size to 4GB when there's 7GB available is just potentially costing your company money.
In setting a heap size of 8GB we are telling node to use more virtual memory than there is physical memory available. If the physical memory is full it will use swap space on disk. This obviously isn't ideal as swap space is slow but if the alternative is a failing build process then I'll just have to live with the disapproval of a random person on the internet.
More broadly speaking, yes this is something we shouldn't need to do. Memory consumption during build should not grow linearly with complexity as it means no-one will build complex apps with Vite. Webpack, while slower, didn't have these problems but even using swap space, vice builds faster so it's still worth it.
Oh and FYI, we have a lot more than 40 modules.

Friend. I don't like your tone at all. Do you know me? Where I work? My Limitations? Please don't be defensive. This isn't a duck measuring contest. Secondly, don't make assumptions. Assumptions is the mother of all fuckups.
I am not on GH Actions runners, as a lot of people. Also I said if it works fine. Go for it. But what will happen if suddenly Vite needs 10-12 Gb? Update your runners? Come on.
Again if it worked for you, fine.  But it doesn't mean everybody can and/or should.
If speed is a question there are other options to take. Code doesn't run faster in faster machines indefinitely. Also the easiest way to run faster is to run less code.
Again, I don't like your tone towards me. That's it from me. Have a nice day!

@patak-dev I wonder if perhaps this issue should be considered an upstream problem with rollup, and closed here, since there is a lot of noise and I think everything that can be said, has been said.


Allow packets to have 3 elements

This is coming out of my agent.

Sorry it should be a < 2, not <= 2.


Add initial user endpoints

Overview
Adding initial users/ api.
Closes #12
Demo
users/

users/{id}

Testing instructions

[ ] Re-run initial migrations, make sure postgresql has the latest schema

Run docker compose rm -v to remove existing database volume

[ ] Run docker compose up --build and make sure everything comes up as expected
[ ] In the browser, navigate to http://localhost:8321/api/users/
[ ] Try POSTing some users
[ ] Try GETing specific users
[ ] Try PUTing a new value for certain fields

Checklist before merge

[ ] Update the CHANGELOG.md
[ ] Rebase your changes from whatever branch you're merging to

Hey sorry for the late entry note, but before you merge, could you also update the API reference in the README?


COPY TO exporting partial data

COPY TO without the optional parameter DIRECTORY exports data from only one shard. I took some time to figure that out....
In my case, the table have 12 shards and the output was to S3, and the generated file had only 1/12 of the total rows.
If the parameter DIRECTORY is provided, all data is exported to S3, generating 12 files.
Tested with version 0.51.2
OS: Ubuntu 14.04

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/26618956-copy-to-exporting-partial-data?utm_campaign=plugin&utm_content=tracker%2F505659&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F505659&utm_medium=issues&utm_source=github).

HI @khalidsalomao,
this is actually expected behaviour and documented in the  and the .
Data is exported from all shards in parallel, overriding each other.

Thanks @mfelsche, it was my mistake (for some reason I thought that was one file per node instead of per shard...).
But, since almost always the index will have multiple shards, this overwrite behavior will cause many mistakes like mine, shouldn't the DIRECTORY option be the default behavior?
Also, in regards to the parallelism, an interesting feature would be to turn off the parallelism and have only 1 resulting file.
AWS Redshift has this option for the UNLOAD command: unload
What do you think about these features:

Make DIRECTORY option the default.

COPY TO with parallelism off to generate only one file (serializing the output of each shard).

New parameter: accept a SELECT query as parameter so that the query output is written to file (similar with the Redshift UNLOAD).

Thanks for the suggestions.
COPY TO is indeed somewhat irritating in this regard.
We will add your point 2. to our backlog, the third one was actually already there, so it gets higher priority.
We will discuss internally the first option. We will definitely fix this, but we are not sure how, yet.
We will keep you posted on this.

Hi @mfelsche, thanks for the feedback!

hi @khalidsalomao, in 0.54 we added the possibility to add a WHERE clause to the COPY TO statement. this should solve your #3. https://crate.io/docs/reference/en/latest/sql/reference/copy_to.html#where-clause

hi @khalidsalomao
If you think @joemoe 's answer solved the initial problem, feel free to close this issue.
Concerning your suggestions (1. and 2.): we don't have them on our roadmap at the moment, but we're happy to take contributions ;-)

:+1:


Sample web UI: downgrade to known working ClojureScript version [phab:D517]

Created by schroederc at 2015-09-16 20:24:42:

shahms accepted this revision at 2015-09-16 20:31:53

schroederc closed via commit f6da9212e8e4f53fdd1c3c06bade00957a4900b7 at 2015-09-16 20:40:10


os/user: add users and groups iterators

Fixes #47907
Go standard library has os/user package which allows to lookup user
or group records via either user/group name or id. This pull request
extends capabilities of os/user package by introducing iteration
functionality for users and groups.
Users and groups iteration functionality might be useful in cases where
a full or partial list of all available users/groups is required in an
application.
On unix, iteration functionality relies
on two internal implementations: one that does not use cgo and parses
contents of /etc/passwd and /etc/group files for users and groups
respectively, and another one that does use cgo and utilizes POSIX
compliant libc library routines getpwent and getgrent for users and
groups respectively. On windows,
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
registry key is iterated for SID values, each SID value represents either
a user or a group.
Tested on Debian GNU/Linux 10 (buster), macOS 11.5.1, freebsd 13.0,
plan9 fourth edition, windows 10 version 21H1.
Comparison of go iterators vs getent (with time -v) with ~17000 entries of users and ~4000 entries of groups:
getent passwd:

User time (seconds): 0.01
System time (seconds): 0.00
Percent of CPU this job got: 100%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.01
Maximum resident set size (kbytes): 2200
Average resident set size (kbytes): 0

go users/groups iterators passwd:

User time (seconds): 0.02
System time (seconds): 0.00
Percent of CPU this job got: 112%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.02
Maximum resident set size (kbytes): 6664
Average resident set size (kbytes): 0

getent group:

User time (seconds): 0.02
System time (seconds): 0.00
Percent of CPU this job got: 100%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.02
Maximum resident set size (kbytes): 3364
Average resident set size (kbytes): 0

go users/groups iterators group:

User time (seconds): 0.00
System time (seconds): 0.00
Percent of CPU this job got: 100%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.00
Maximum resident set size (kbytes): 4144
Average resident set size (kbytes): 0

The proposal was declined; closing.


Upgrade the version of styled-components

styled-components 2.0 is still in alpha/beta right? Should we be upgrading right now? 🤔

@timneutkens yep.
@Alex4S let's do this after they released it.
Basically, we wanted to show about how to use styled-components. I think that idea is there even someone is using the latest beta of styled-components.

@arunoda in styled-components 2.0 this is fixed https://github.com/zeit/next.js/tree/master/examples/with-styled-components#notes.

@timneutkens styled-components 2.0 is pre-release now and you are right this issue is fixed.

Works fine with 2.0.0-1 but has incorrect ids in 2.0.0-4

@alexedev Same for me. Issue reported here: https://github.com/styled-components/styled-components/issues/513

Fyi, the version currently used in the example breaks when using ThemeProvider so it might be good idea to update it to the latest 1.x version, even tho 2.x will be released soon.

@rovansteen I'll do that 👍


Project clone should respect workspace CAs

Project clone should respect workspace CAs.
It's critical for airgap mode of CRW, where devfile registry serves projects as zip archives though self-signed https. Note: as alternative we could use internal network which is HTTP, but then we have another issue that NetworkPolicies should be configured in the corresponding way.

This feature is supported by automounting secrets/configmaps and the (current) project clone container. To add a self-signed cert to your DevWorkspace, the process is

Get the certificate (e.g. for testing with the devfile registry and crc, get the crc ingress operator cert)
Create a secret from the cert:kubectl create secret generic selfsigned-cert-secret \
  --from-file=cluster.crt=/path/to/cert/from/step/one

Annotate the secret to be mounted to DevWorkspaces:kubectl patch secret selfsigned-cert-secret --type merge -p \
  '{
    "metadata": {
      "labels": {
        "controller.devfile.io/mount-to-devworkspace": "true"
      },
      "annotations": {
        "controller.devfile.io/mount-path": "/usr/local/share/ca-certificates/"
      }
    }
  }'


Tooltip content doesn't wrap

Describe the bug
Tooltip doesn't wrap and goes off the screen on small screen sizes
Expected behavior
Tooltip should wrap so that all tooltip text is visible and not off-screen
Screenshots

Rimble UI Version

latest

Desktop (please complete the following information):

Mac OS
Brave
0.63.48

Additional context
This was using a desktop browser, but I changed the window size to see what it would display like on a mobile device.

Needs additional research to find possible solutions. @MikeLockz will add a failing example.

Example: https://codesandbox.io/embed/heading-margin-bug-bhe6u
I think we can close this issue if we move the tooltip placement to the bottom.

Couldn't recreate in sandbox. Resolved by new layout in app.


[Bug]: Error occurs at startup and data cannot be loaded or saved

What happened?
A bug happened!
When I start Stats, I get the error in (1). (It appears twice in a row.)
The program automatically becomes resident and the main screen is not displayed.
For some reason, the overlay is also not displayed, and when I display it from the resident part, the font has changed, and the last round played is also displayed as "N/A" and it looks as if the data has disappeared (2).
When I try to close the application at the end, the error message (3) appears.
Is the data safe? Is it possible to recover from this?
(1)

(2)

(3)

data.db.zip
Player.log
Platform
Steam

data.zip
Try it with this file.

data.zip
Try it with this file.

Thank you!
I'm able to start it up now,
Is it safe to get an error like this?
It says in Japanese: "An object of type 'System.Int32' cannot be cast to type 'LiteDB.ObjectId'".

Download the new version 1.330 and check if there is a problem by running the exe file and data.db file in one place.

Download the new version 1.330 and check if there is a problem by running the exe file and data.db file in one place.

I re-downloaded and ran it with only the Data.db file and the exe file and it solved the problem.
Thank you for your response.


OCPBUGS-24931: Rebase etcd 3.5.11 openshift 4.16

This PR rebases etcd 3.5.11 into openshift-4.16.
This PR has been created by this workflow

git rebase --rebase-merges --fork-point v3.5.10 v3.5.11 ( rebasing the changes from upstream 3.5.10 --> 3.5.11 )
git cherry-pick -m 1 c89a29056e881a1862dda376fc3ba5002121f289 to cherrypick the downstream changes (commit)
git cherry-pick -m 1 969d7af to cherrypick ART changes (commit)

After rebasing, running make locally produce
SUCCESS: etcd_build (GOARCH=amd64)
./bin/etcd --version
etcd Version: 3.5.11
Git SHA: f60bb6fa4
Go Version: go1.21.1
Go OS/Arch: darwin/amd64
./bin/etcdctl version
etcdctl version: 3.5.11
API version: 3.5
./bin/etcdutl version
etcdutl version: 3.5.11
API version: 3.5

cc @hasbro17 @dusk125 @tjungblu @soltysh @deads2k

/payload 4.16 nightly informing

/payload 4.16 nightly blocking

/jira refresh

/jira refresh

Blocking jobs are successful

informing jobs are successful, only ipi-metal-ipv6 still running
2023-12-10 20:43:18 +0000 UTC: AllJobsFinished: AllJobsFinished: jobs [periodic-ci-openshift-release-master-nightly-4.16-e2e-metal-ipi-upgrade-ovn-ipv6,periodic-ci-openshift-release-master-nightly-4.16-upgrade-from-stable-4.15-e2e-metal-ipi-upgrade-ovn-ipv6] still running
2023-12-10 16:39:24 +0000 UTC: AllJobsTriggered: AllJobsTriggered: All jobs triggered successfully

/retest-required

/lgtm

/retest-required

/retest-required

/jira refresh

/remove-label jira/invalid-bug
/label jira/valid-bug

/retest-required

/refresh

/retest-required

/pj-rehearse ack

/pj-hearse help

/close

/reopen

reopened in https://github.com/openshift/etcd/pull/237


2 links being active at same time (color of links)

I'm trying to get each link to have a solid color when active. It works flawlessly until I get to the last link "contact". When I navigate to "contact", it becomes active along with the previous one. So then I have 2 solid color links, when only "contact" should be solid. I took 2 screenshots, click on both links to reference:
https://imgur.com/sedwrZA
https://imgur.com/WI5Ae28

Are both the elements visible in the viewport?
But please provide a plunkr/codepen to demonstrate the issue and I could take a look at it.

Yes both elements are visible in the view port. I was able to come up with a hacky solution by increasing the margin on my bottom div, but then I dont get the view I want. Is there a way to force only 1 link being active when both elements are visible?

Maybe you could listen to the events on the elements being activated/inactivated and come up with your own logic to activate only one of them.


Point Cloud ghost pixels

Python Library versions

Run pip list | grep TauLidar in the command-line and paste the output. Include some details on your system as well

TauLidarCamera            0.0.1
TauLidarCommon            0.0.1
TauLidarServer            0.0.1.post2

Running on Mac
Camera Info

If possible, paste the output of camera.info() from Python (after camera has been successfully opened)

ToF camera opened successfully:
    model:      4.0
    firmware:   3.3
    uid:        69.549
    resolution: 160x60
    port:       /dev/cu.usbmodem00000000001A1
    IP address: <IP_ADDRESS>
    URL:  http://<IP_ADDRESS>:8081

Describe the bug
The point cloud visualization in the browser holds on to "ghost" pixels. These are pixels that had a depth measurement in a previous camera frame, but after the camera was moved there was no depth data for this x,y coordinate, resulting in the previous depth measurement staying in the point cloud and not being cleared.
This results in some strange looking frames
Steps to Reproduce

Run the TauLidarServer python program
point the camera at a scene
move the camera to point at a scene where some parts of the depth map are an undefined distance
Observe point cloud has "ghost" pixels left over from the frames of scene in step 2 overlaid with the point cloud from the scene in step 3

What is expected?
The point cloud should not include any points from previous frames. Each frame should be independent
What is actually happening?
Parts of the point cloud that used to have a distance measurement and now do not stay in the point cloud.
Previous frame:

Next frame with ghost pixels circled in green:

Any additional comments?
See screen capture for an illustration of the issue at 0:07 and 0:12
https://youtu.be/hVjc9lZJRXA

Ghost pixels remains when updated frame is missing data on the corresponding coordinates.
Issue can be resolved by reinitializing the point cloud scene every time when new frame updates.
Fixed in 6102a79e08341e6a275764a4fbf2a5108aa4a7d5

released in v0.0.3


If we drag the stone near to the monster the stone stays at the same position and it will not take as the input.

Describe the bug
Here when ever we drag the stone to the monster's month the stone stays at that position and will not be able to give the input.
(This issue is Happening in Hindi and English.)
To Reproduce
Steps to reproduce the behavior:

Download Hindi , and open the first puzzle.
Drag the stone to the monster as shown in the below video near to the area where we give the input.
Then if we try to drop the stone it remains in the same position.

LOGS
log for stone dragging issue.txt
Screen Record
https://github.com/curiouslearning/FeedTheMonsterJS/assets/99384703/eb47505e-69c5-4141-aaf5-1c82a3e364bd
Smartphone (please complete the following information):

Device: MI Note 6 pro
OS: Android 9

Additional context
Add any other context about the problem here.

Let's just check this when we push #1001 to see if this still happens or if that somehow resolves this.


added range support in slider

Describe your changes
Added range support in slider
Screenshots [Optional]
Issue ticket number and link
Closes #789
Checklist before requesting a review

[x] I have performed a self-review of my code
[ ] I have added tests
[x] I have added a changeset pnpm changeset add
[x] I have added example usage in the kitchen sink app

@evshi  Here is the documentation link of Slider widget
https://ant.design/components/slider


Report pre-requisite

[Enter feedback here]
Hi Everyone,
in this page I've read taht the report is available for Admin Global Reader AND Reports reader (in the pre-requisite section), but my Azure Admin says that it's only available to Administrator and not to Reports Reader.
Can you plese verify and eventually correct the article (or correct my Azure admin :-D)
Thank you and ciao
Stefano

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 67197abd-ee35-668f-c454-eb4b07f4a6f9
Version Independent ID: 647d2380-5ddd-cc17-9f43-93773ff75b9c
Content: OneDrive sync reports in the Apps Admin Center - OneDrive
Content Source: OneDrive/sync-health.md
Service: one-drive
GitHub Login: @mkbond007
Microsoft Alias: mabond

Thank you for submitting feedback.
I think the best way forward is if you open a service ticket in your tenant so this can get resolved ASAP. Based on the outcome let me know if it is something that can be called out in the docs.
Please follow this link to contact support for business products:https://docs.microsoft.com/office365/admin/contact-support-for-business-products
Please keep us posted here on the resolution so we can feed whatever information you discover into the content.


Fix React Native build

After installing @nhost/react and @nhost/react-apollo into a React Native 0.69.1 project, attempting to start the Metro bundler fails:
$ npm run start

><EMAIL_ADDRESS>start
> react-native start

error Failed to load configuration of your project.
Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './package.json' is not defined by "exports" in<EMAIL_ADDRESS>
    at new NodeError (node:internal/errors:372:5)
    at throwExportsNotFound (node:internal/modules/esm/resolve:472:9)
    at packageExportsResolve (node:internal/modules/esm/resolve:753:3)
    at resolveExports (node:internal/modules/cjs/loader:482:36)
    at Function.Module._findPath (node:internal/modules/cjs/loader:522:31)
    at Function.Module._resolveFilename (node:internal/modules/cjs/loader:919:27)
    at Function.resolve (node:internal/modules/cjs/helpers:108:19)
    at resolveNodeModuleDir (/Users/dmitry/dev/phenomenological/node_modules/@react-native-community/cli-tools/build/resolveNodeModuleDir.js:24:42)
    at /Users/dmitry/dev/phenomenological/node_modules/@react-native-community/cli-config/build/loadConfig.js:93:76
    at Array.reduce (<anonymous>)
info Run CLI with --verbose flag for more details.

This PR changes package.json to fix that issue. I followed this example: https://github.com/uuidjs/uuid/commit/2e93665bad99edfb39f50df3e2460751357580bd.

Codecov Report

Merging #828 (34470ff) into main (d019f1d) will decrease coverage by 0.02%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##             main     #828      +/-   ##
==========================================
- Coverage   93.47%   93.44%   -0.03%
==========================================
  Files          42       42
  Lines        6434     6436       +2
  Branches      377      377
==========================================
  Hits         6014     6014
- Misses        420      422       +2

Impacted Files
Coverage Δ

packages/core/src/storage.ts
47.72% <0.00%> (-0.74%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b8e787c...34470ff. Read the comment docs.

Hey @dminkovsky! Thanks for fixing this. Could you please add package.json to other packages' exports field too?

Thanks @plmercereau ! Not sure why it didn't occur to me to check the other packages :). Thanks for doing it.


Add HEP for PCI-PT [CI SKIP]

Problem:
To enable VMs in Harvester to directly use PCI devices in the host cluster.
Solution:
Released in 1.1.0, PCI Passthrough is an experimental addon that enables the stories described in this HEP. This PR is to formalize the feature as an HEP, as the original HEP remained in Draft form while we shipped the feature.
NOTE:

https://github.com/tlehman/harvester/blob/hep-pcipt/enhancements/20220722-pci-passthrough.md

Related Issue:

https://github.com/harvester/harvester/issues/992
https://github.com/harvester/harvester/issues/1029
https://github.com/harvester/harvester/issues/2429

Test plan:
CI Disabled for this PR, since it's just static markdown documents.

we should also cover the behavior of pcidevices controller when device is part of a iommu group.

Done


Animation for sliding in and out

Default bug for slide animation.

Setting as done after merge of version 0.1.0. The animation is done by the material-ui package and therefore will stay the same in most circumstances.


Centralizing Slides

Added margin auto on slick-track, to center slides if no have a minimum in the cases of dynamic slides

This might be better as just a class that is added so that people can implement the not enough slides styles how they'd like to, as opposed to implicit centering

of course, but as in my test this feature had no side effect I think this
behavior could be native
2015-10-03 13:25 GMT-03:00 Ken Wheeler<EMAIL_ADDRESS>
This might be better as just a class that is added so that people can
implement the not enough slides styles how they'd like to, as opposed to
implicit centering
—
Reply to this email directly or view it on GitHub
https://github.com/kenwheeler/slick/pull/1794#issuecomment-145262901.

--
[image: http://frango.herokuapp.com] http://frango.herokuapp.com
Leandro CunhaEmpreendedor motivado Front-End ExpertBack-End autodidata
http://frango.herokuapp.com http://frango.herokuapp.com/


Fields in the top nav bar are not in alignment

On master-head - commit id: 5a60e25bd

Navigate to dashboard

Top nav is as below

Click on Shell in the top nav bar

Cluster Explorer and cluster dropdown, are misaligned

Duplicate: https://github.com/rancher/dashboard/issues/1497


Refactored Component Initialization, Support Custom Request Headers

Re: #8

cc @matteofigus

:+1: looks good