realm / realm-js

Realm is a mobile database: an alternative to SQLite & key-value stores
https://realm.io
Apache License 2.0
5.78k stars 575 forks source link

Vite Build Fails #3863

Closed ChaosDeSelva closed 3 years ago

ChaosDeSelva commented 3 years ago

Goals

Build an app with Vite 2, Vue 3 and Realm-js

Any help is greatly appreciated. I have spent a day fumbling around rollup and vite configs trying to figure something out to make it work with realm because out of the box it is not.

Expected Results

The build is successful, I get something like this,

> vite build

vite v2.4.2 building for production...
✓ 9 modules transformed.
dist/index.html                  0.49kb
dist/assets/index.ccce2ca3.css   0.16kb / brotli: 0.10kb
dist/assets/index.4e65d379.js    0.12kb / brotli: 0.10kb
dist/assets/vendor.d775000a.js   44.30kb / brotli: 15.93kb

Actual Results

As soon as I add

import * as Realm from "realm-web"; 

vite build stops working. I suspect it has something to do with the BSON dep but I am not sure.

vite build

vite v2.4.2 building for production...
transforming (9) node_modules/@vue/shared/dist/shared.esm-bundler.js
<--- Last few GCs --->

[22473:0x104c00000]    46177 ms: Mark-sweep (reduce) 4336.6 (4342.3) -> 4157.9 (4163.7) MB, 1838.0 / 0.0 ms  (average mu = 0.200, current mu = 0.151) allocation failure scavenge might not succeed
[22473:0x104c00000]    47736 ms: Mark-sweep (reduce) 4157.9 (4163.7) -> 4157.9 (4163.7) MB, 1559.5 / 0.0 ms  (average mu = 0.108, current mu = 0.000) allocation failure scavenge might not succeed

<--- JS stacktrace --->

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x101317585 node::Abort() (.cold.1) [/Users/me/.nvm/versions/node/v14.17.3/bin/node]
 2: 0x1000b25c9 node::Abort() [/Users/me/.nvm/versions/node/v14.17.3/bin/node]
 3: 0x1000b272f node::OnFatalError(char const*, char const*) [/Users/me/.nvm/versions/node/v14.17.3/bin/node]
 4: 0x1001f6eb7 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/Users/me/.nvm/versions/node/v14.17.3/bin/node]
 5: 0x1001f6e53 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/Users/me/.nvm/versions/node/v14.17.3/bin/node]
 6: 0x1003a6eb5 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/Users/me/.nvm/versions/node/v14.17.3/bin/node]
 7: 0x1003a897a v8::internal::Heap::RecomputeLimits(v8::internal::GarbageCollector) [/Users/me/.nvm/versions/node/v14.17.3/bin/node]
 8: 0x1003a4049 v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/Users/me/.nvm/versions/node/v14.17.3/bin/node]
 9: 0x1003a18e1 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/Users/me/.nvm/versions/node/v14.17.3/bin/node]
10: 0x1003a22f2 v8::internal::Heap::CollectAllAvailableGarbage(v8::internal::GarbageCollectionReason) [/Users/me/.nvm/versions/node/v14.17.3/bin/node]
11: 0x1003b025e v8::internal::Heap::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/Users/me/.nvm/versions/node/v14.17.3/bin/node]
12: 0x100376d57 v8::internal::FactoryBase<v8::internal::Factory>::NewFixedArrayWithFiller(v8::internal::Handle<v8::internal::Map>, int, v8::internal::Handle<v8::internal::Oddball>, v8::internal::AllocationType) [/Users/me/.nvm/versions/node/v14.17.3/bin/node]
13: 0x10050a3a2 v8::internal::(anonymous namespace)::ElementsAccessorBase<v8::internal::(anonymous namespace)::FastPackedObjectElementsAccessor, v8::internal::(anonymous namespace)::ElementsKindTraits<(v8::internal::ElementsKind)2> >::GrowCapacity(v8::internal::Handle<v8::internal::JSObject>, unsigned int) [/Users/me/.nvm/versions/node/v14.17.3/bin/node]
14: 0x1006d64b4 v8::internal::Runtime_GrowArrayElements(int, unsigned long*, v8::internal::Isolate*) [/Users/me/.nvm/versions/node/v14.17.3/bin/node]
15: 0x100a8a919 Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_NoBuiltinExit [/Users/me/.nvm/versions/node/v14.17.3/bin/node]
Abort trap: 6

I did export NODE_OPTIONS=--max_old_space_size=16000 that did not help.

Steps to Reproduce

Create a hello world vite and vue app, include realm-js, do npm run build.

if I comment out import * as Realm from "realm-web"; vite will build with success.

Code Sample

App.vue

<template>
    <p>hello</p>
</template>

<script>
import * as Realm from "realm-web";
</script>

package.json

{
  "name": "vue3-vite2-realmjs-test",
  "version": "0.0.0",
  "scripts": {
    "dev": "vite",
    "build": "vite build"
  },
  "dependencies": {
    "realm-web": "^1.3.0",
    "vue": "^3.1.5"
  },
  "devDependencies": {
    "@vue/compiler-sfc": "^3.1.5",
    "@vitejs/plugin-vue": "^1.2",
    "vite": "^2.4.2"
  }
}

vite.config.

import { defineConfig } from 'vite'
import vue from '@vitejs/plugin-vue'

export default defineConfig({
  plugins: [vue()],
})
ChaosDeSelva commented 3 years ago

This might help. I am just trying to get it to build, not much else going on in this repo.

https://github.com/ChaosDeSelva/realm-prototype

takameyer commented 3 years ago

@ChaosDeSelva Thanks for reporting and providing the example code! That will be very helpful. We will investigate this and notify you as soon as we have any progress.

takameyer commented 3 years ago

@ChaosDeSelva You are correct that the problem lies in the BSON dependency. When I remove realm-web from the project and only use bson, the problem persists. We will have to reach out to those responsible and see if we can find a solution.

ChaosDeSelva commented 3 years ago

@takameyer thanks for looking into this, I really appreciate it. I am using realm-js on a few projects, I really like it. Hopefully it is an easy fix for the team. I went over to the BSON github, it redirected me to the mongo node jira. I submitted a ticket https://jira.mongodb.org/browse/NODE-3462 please feel free to make adjustments to the request. I also pushed a BSON branch for the ticket https://github.com/ChaosDeSelva/realm-prototype/tree/bson-test

takameyer commented 3 years ago

@ChaosDeSelva I have been in contact with the team responsible for BSON. It appears the devDependency rollup has a bug relating to this memory issue, and it seems to effect bson in a meaningful way. (see issue https://github.com/rollup/rollup/issues/4181). We will have to wait until they have fixed this and released an update.

In the meantime, a work around is to apply the following patch to you package-lock.json. This will downgrade rollup and should fix the issue.

diff --git a/package-lock.json b/package-lock.json
index 6669298..b9fbf0d 100644
--- a/package-lock.json
+++ b/package-lock.json
@@ -466,9 +466,9 @@
       }
     },
     "rollup": {
-      "version": "2.53.2",
-      "resolved": "https://registry.npmjs.org/rollup/-/rollup-2.53.2.tgz",
-      "integrity": "sha512-1CtEYuS5CRCzFZ7SNW5528SlDlk4VDXIRGwbm/2POQxA/G4+7/crIqJwkmnj8Q/74hGx4oVlNvh4E1CJQ5hZ6w==",
+      "version": "2.53.1",
+      "resolved": "https://registry.npmjs.org/rollup/-/rollup-2.53.1.tgz",
+      "integrity": "sha512-yiTCvcYXZEulNWNlEONOQVlhXA/hgxjelFSjNcrwAAIfYx/xqjSHwqg/cCaWOyFRKr+IQBaXwt723m8tCaIUiw==",
       "dev": true,
       "requires": {
         "fsevents": "~2.3.2"
ChaosDeSelva commented 3 years ago

@takameyer Thanks for the follow up.

The BSON team updated the Jira ticket this morning pointing out rollup pushed a fix this morning. https://github.com/rollup/rollup/releases/tag/v2.53.3

Thanks for the help, I will close this issue. Everything is working for me now using 2.53.3