Building Nitro Server - Out Of Memory #582
Labels
Comments
|
nitrojs/nitro#102 related issue |
|
https://rollupjs.org/guide/en/#error-javascript-heap-out-of-memory I think it's related to rollup, which is used in nitro builder. That was the reason for me to migrate from webpack to vite. It drastically reduces bundle size, but also causes some difficulties |
|
+1 same issue for me. Upgrade from nuxt 2 to bridge. I can build locally but am unable to build using github actions |
|
As a workaround, I disabled nitro which allows me to stay on nuxt-edge and bridge. export default defineNuxtConfig({ |
|
I had the same issue during the migration of the bigger Nuxjt2 app. Tried almost everything. I found out that the problem only disappeared after setting up the |
|
traced break point, it occurs when rollup build (nitropack: node_modules/nitropack/dist/shared/nitro.775e1ce4.mjs) |
|
build pass with increase memory through NODE_OPTIONS, but this is temporary solution |
#582 (comment) this is exactly what Rollup suggests. Anyway, vite builder producess 4x compact output, in comparison to webpack |
|
When I using nuxt3 with vercel, 8192 seems still not enough - vercel kills the build with |
|
Same issue for me, did u find any solutions ? |
Skip nuxt/bridge and migrate to the nuxt 3 directly. Only that worked for me, there were plenty of things that looked to me buggy in nuxt/bridge. |
Indeed, do you have some advice to directly migrate to Nuxt 3, i'm working on a pretty big project 😬 |
Ask your company to pick a month or two when you will stop all development and will work on Nuxt 3 Migration. That's what we did. We even split migration into two steps: reworking all inject functions to composables (with Nuxt CAPI instead of Bridge) and second step is Nuxt 3 migration (didn't start yet). That's the only way I guess for very big projects. |
|
Like @daniluk4000 said, its good to map everything that migration needs to cover. I started the following way:
I know it's sometimes a pain, but I also spent around a month for the whole upgrade, and still, not every component is done. Additionally, because the migration covers implications for change in almost all codebases, this time is also good for considering whether to stick with Nuxt or go with Remix or Next, which seems to have a larger community using it. I am giving a chance for nuxt, but the nuxt/bridge sucks, and it made me seriously think about other solutions. |
Did the same in our "first step", didn't mention before. Pinia also offers much better experience!
For everyone there: this is not something required (at least not for most of components) and you still can use OAPI. Simply return your composables/refs e.t.c. in setup and use it in methods, like <template>...</template>
<script>
import { defineComponent, reactive } from 'vue';
export default defineComponent({
name: 'ComponentName',
setup() {
const options = reactive({});
return {
options,
}
},
methods: {
updateOptions() {
this.options.foo = 'bar';
},
},
});
</script>That's what we had to do as we have hundreds of components - too much effort to migrate them all to CAPI. Also, Vue 3 Documentation states that Options API will not be deprecated. We only use setup for new components and use OAPI/CAPI combination for old components.
I am myself was really not happy about migration process. Migration of all codebase directly to Nuxt 3 + Vue 3 without any preparation steps was very risky for us and we could stuck for more than a month or two with that. I was very disappointed and in order to get our migration done, as we can't use Bridge, I had to make a PR (which we use in production now) in Nuxt CAPI plugin (nuxt-community/composition-api#742) so we can start using CAPI and migrate required parts of codebase to it. But. Nuxt 3 is a masterpiece. I was using it since RC and use now in separate small project (not this one we have to migrate) and DX there is so good. Personally, I recommend to finish migration or at least try using Nuxt 3 somewhere. Migration process is pain for both Vue 3 and Nuxt 3, for some projects like our it can become a large pain, but in the end Nuxt 3 is way higher in it's experience than Nuxt 2. Nuxt team did a great job there. And, speaking of migration, still migration to Nuxt 3 from Nuxt 2 should be anyway faster than going to like Next or something else. I would (and will) give it a try. |
|
Even if this problem is not resolved, nuxt/bridge can still be used. Note that this problem only seems to occur with webpack, so try replacing it with vite. |
|
With Webpack, nitro, ssr: true & target: 'static' we got this to work By adding sourceMap: false in nitro we were able resolve memory leak |
|
I also faced this problem, but I solved it by removing |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Environment
Darwinv16.17.02.16.0-27720022.54e852f0.5.4[email protected]webpackbridge,alias,runtimeConfig,head,router,axios,proxy,auth,css,styleResources,plugins,components,buildModules,modules,analytics,svgSprite,i18n,build,builder,sentry,serverHandlers,devServerHandlers[email protected],@nuxtjs/[email protected],@nuxtjs/[email protected],@nuxtjs/[email protected],@nuxtjs/[email protected],@nuxtjs/[email protected],@nuxtjs/[email protected],[email protected],[email protected],portal-vue/nuxt(),@nuxtjs/[email protected],@nuxt/[email protected]Reproduction
it's hard to reproduction, I've attached a build log, it may helps. (filesize, volumes, ...)
Describe the bug
completed client, server build but nitro build fails oom.
Additional context
M1 Pro / 32GB RAM
Logs
The text was updated successfully, but these errors were encountered: