Vue CLI's type checking service ignores memory limits
Asked Answered
S

3

22

DevOps has requested that we limit our frontend builds to ~1GB of RAM, so that our Jenkins instance doesn't shut down. We use a standard @vue/cli project, with TypeScript. However, the TS type checking service ignores all attempts to limit its memory usage, which is always 2048 MB.

I've tried disabling it and relying on fork-ts-checker-webpack-plugin but that introduces other problems.

Based on what I found, this should work:

$ NODE_OPTIONS=--max_old_space_size=1024 \
    NODE_ENV=production \
    node \
    --max_old_space_size=1024 \
    --max-old-space-size=1024 \
    node_modules/.bin/vue-cli-service build

Note that I've no idea how these memory limits work, as I have limited awareness of Node's internals. But despite these, the type checking service always starts with a 2048 MB limit.

I'm not sure if it's a problem specific to how Vue CLI configures Webpack/TS.

Shavonneshaw answered 20/3, 2019 at 10:18 Comment(0)
E
25

I ran into the same issue (although in my case, I wanted to raise the memory limit instead of lower it). I was able to modify the configuration of the ForkTsCheckerWebpackPlugin by customizing Vue CLI's built-in webpack.config:

// in vue.config.js

const ForkTsCheckerWebpackPlugin = require('fork-ts-checker-webpack-plugin');

module.exports = {
  configureWebpack: config => {

    // get a reference to the existing ForkTsCheckerWebpackPlugin
    const existingForkTsChecker = config.plugins.filter(
      p => p instanceof ForkTsCheckerWebpackPlugin,
    )[0];

    // remove the existing ForkTsCheckerWebpackPlugin
    // so that we can replace it with our modified version
    config.plugins = config.plugins.filter(
      p => !(p instanceof ForkTsCheckerWebpackPlugin),
    );

    // copy the options from the original ForkTsCheckerWebpackPlugin
    // instance and add the memoryLimit property
    const forkTsCheckerOptions = existingForkTsChecker.options;
    forkTsCheckerOptions.memoryLimit = 8192;

    config.plugins.push(new ForkTsCheckerWebpackPlugin(forkTsCheckerOptions));
  },
};

Now when I run my build, I see this in my output:

-  Building for production...
Starting type checking service...
Using 1 worker with 8192MB memory limit

More info on the configureWebpack option here: https://cli.vuejs.org/config/#configurewebpack

To see the default Webpack configuration used by the Vue CLI, you can inspect it by running vue inspect: https://cli.vuejs.org/guide/webpack.html#inspecting-the-project-s-webpack-config

Eddaeddana answered 23/4, 2019 at 11:43 Comment(2)
Thanks for the tip. I no longer work at that same place so I can't check if your solution is the correct one, but it seems like it!Shavonneshaw
I tried 2 and 4 workers instead of 1 and also 8GB memory instead of default 2GB. No noticable difference. Any explanation for this? Seems like this proposal has rather an esoteric effect...Resort
U
14

in vue.config.js

const ForkTsCheckerWebpackPlugin = require('fork-ts-checker-webpack-plugin');
const os=require('os');
module.exports = {
    //......,
    chainWebpack: config => {
        config
            .plugin('fork-ts-checker')
            .tap(args => {
                let totalmem=Math.floor(os.totalmem()/1024/1024); //get OS mem size
                let allowUseMem= totalmem>2500? 2048:1000;
                // in vue-cli shuld args[0]['typescript'].memoryLimit
                args[0].memoryLimit = allowUseMem;
                return args
            })
    },
   //......
}
Ungovernable answered 5/6, 2019 at 10:59 Comment(1)
This solution worked for me. Just to be clear, this piece of code in my project was preceded by configureWebpack{},Inspectorate
P
0

in node_modules/fork-ts-checker-webpack-plugin/lib/index.js

declare class ForkTsCheckerWebpackPlugin {
    static readonly DEFAULT_MEMORY_LIMIT = 4096;
    static readonly ONE_CPU = 1;
    static readonly ALL_CPUS: number;
    static readonly ONE_CPU_FREE: number;
    static readonly TWO_CPUS_FREE: number;
    readonly options: Partial<Options>;
Pend answered 25/5, 2020 at 6:24 Comment(1)
Disagree. One npm update - that one should regularly - and that config is gone or needs to be remembered to be redoneWetmore

© 2022 - 2024 — McMap. All rights reserved.