Out of memory when building with Vite and GitLab & possible solution

[ajmas]

TL;DR:

Recently I ran into an out of memory issue when building our Vite/Quasar project in GitLab continuous integration and worked around it by disabling the linting during CI.

I have run into an out of memory condition in the past, when using webpack/Quasar, and increasing heap space, as some posts suggest, but this is not an option since it ends up causing the build process to slow to a crawl, probably due to excessive swapping due to exceeding the VM size.

In depth:

Our build in GitLab failed due to a "heap limit Allocation failed - JavaScript heap out of memory". We updated all our dependencies to latest, but that did not make a difference. This meant we needed to take a different approach.

So the failure we got was as follows:

Use of eval is strongly discouraged, as it poses security risks and may cause issues with minification
Use of eval is strongly discouraged, as it poses security risks and may cause issues with minification
Use of eval is strongly discouraged, as it poses security risks and may cause issues with minification
Use of eval is strongly discouraged, as it poses security risks and may cause issues with minification
<--- Last few GCs --->
[102:0x59c9430]   173982 ms: Mark-sweep (reduce) 1835.8 (1872.6) -> 1834.4 (1872.8) MB, 3020.2 / 0.0 ms  (average mu = 0.110, current mu = 0.006) allocation failure scavenge might not succeed
[102:0x59c9430]   177114 ms: Mark-sweep (reduce) 1835.8 (1872.8) -> 1834.5 (1872.3) MB, 3103.9 / 0.0 ms  (average mu = 0.061, current mu = 0.009) allocation failure scavenge might not succeed
<--- JS stacktrace --->
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0xafedf0 node::Abort() [node]
 2: 0xa1814d node::FatalError(char const*, char const*) [node]
 3: 0xce792e v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [node]
 4: 0xce7ca7 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [node]
 5: 0xeb1685  [node]
 6: 0xeb2174  [node]
 7: 0xec05e7 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [node]
 8: 0xec399c v8::internal::Heap::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node]
 9: 0xe85f25 v8::internal::Factory::AllocateRaw(int, v8::internal::AllocationType, v8::internal::AllocationAlignment) [node]
10: 0xe80e29 v8::internal::FactoryBase<v8::internal::Factory>::AllocateRawArray(int, v8::internal::AllocationType) [node]
11: 0xe80ee5 v8::internal::FactoryBase<v8::internal::Factory>::NewFixedArrayWithFiller(v8::internal::Handle<v8::internal::Map>, int, v8::internal::Handle<v8::internal::Oddball>, v8::internal::AllocationType) [node]
12: 0xe8da91 v8::internal::Factory::NewJSArrayStorage(v8::internal::ElementsKind, int, v8::internal::ArrayStorageAllocationMode) [node]
13: 0xe8dbae v8::internal::Factory::NewJSArray(v8::internal::ElementsKind, int, int, v8::internal::ArrayStorageAllocationMode, v8::internal::AllocationType) [node]
14: 0x[120](https://gitlab.com/otakuthon/scarlet-staff-frontend/-/jobs/3259012138#L120)9386 v8::internal::Runtime_StringSplit(int, unsigned long*, v8::internal::Isolate*) [node]
15: 0x15c9eb9  [node]
Aborted (core dumped)

The test stage in the .gitlab-ci.yml:

  image: node:16
  cache:
    <<: *node_cache
  stage: test
  variables:
    ENV: devci
    NODE_ENV: 'test'
  script:
    - yarn --link-duplicates
    - NODE_ENV=production
    - yarn run build

What ended up working for us, is running the linter outside of Quasar, as a suggested by one of our devs:

So in the .gitlab-ci.yml we adjusted the script in the stage to be:

  script:
    - export CONTINUOUS_INTEGRATION=1
    - yarn --link-duplicates
    - NODE_ENV=production
    - yarn run lint
    - yarn run build

and then in our quasar.conf.js:

// make sure CONTINUOUS_INTEGRATION this is set in the CI configuration
const isCI = process.env.CONTINUOUS_INTEGRATION === '1';

console.log(' CI.....................', isCI ? 'yes' : 'no', '\n');

module.exports = configure(function (ctx) {
  return {
    eslint: isCI ? {
      warnings: false,
      errors: false
    } : {
      // fix: true,
      // include = [],
      // exclude = [],
      // rawOptions = {},
      warnings: true,
      errors: true
    },

BTW I could have used the is-ci package to see if we were in a CI environment, but the environment variable was enough for our needs.

I am sharing this in case it helps someone else or if anyone sees another approach to this. Also, whether this would be something worth adding to the https://quasar.dev/quasar-cli-vite/linter#disabling-linter page in some form?

A future task would be to do memory profiling of the quasar build and see how it varies and spot any potential risk points.