npm build not working

[cameronmackinnon]

Have been trying to figure out an issue with the node.js CI build for the past few days but having no luck. It seems to be working off and on and I cannot figure out why it works sometimes and sometimes it does not. Most of the time the error from the Node.js CI build looks like what I copied below. The specific page that crashes changes each time (sometimes resume, sometimes contact, etc.). It is always failing on the build portion, but the node-version & os are also random (e.g., sometimes it's mac-os, other times it's ubuntu 18.x).

The local version is working fine. And I've had several successful builds - but then I add a comment, try to build again, and it fails.

I feel like I've tried everything - uninstalling and reinstalling npm; performing the double npm install; using npm audit fix; re-cloning the original repo instead of using the fork.

I've also had "failed to launch chrome" errors. I took a look at this thread puppeteer/puppeteer#2207 but it doesn't seem to have many solutions.

If anyone has any insight into what I'm doing wrong, it'd be greatly appreciated! Thanks.

---

Run npm run predeploy

personal-site@4.0.0 predeploy
npm run build && react-snap

personal-site@4.0.0 build
rimraf ./build && react-scripts build

Creating an optimized production build...
One of your dependencies, babel-preset-react-app, is importing the
"@babel/plugin-proposal-private-property-in-object" package without
declaring it in its dependencies. This is currently working because
"@babel/plugin-proposal-private-property-in-object" is already in your
node_modules folder for unrelated reasons, but it may break at any time.

babel-preset-react-app is part of the create-react-app project, which
is not maintianed anymore. It is thus unlikely that this bug will
ever be fixed. Add "@babel/plugin-proposal-private-property-in-object" to
your devDependencies to work around this error. This will make this message
go away.

Compiled successfully.

File sizes after gzip:

80.2 kB build/static/js/main.0d7a0995.js
7.66 kB build/static/css/main.d7970cf6.css
7.64 kB build/static/js/131.282dc151.chunk.js
6.23 kB build/static/js/745.4cdb9fc4.chunk.js
4.73 kB build/static/js/161.51b6b8a0.chunk.js
4.36 kB build/static/js/209.e1f55257.chunk.js
830 B build/static/js/117.6b446b74.chunk.js
791 B build/static/js/478.b5e04956.chunk.js
478 B build/static/js/964.145423e4.chunk.js
387 B build/static/js/922.a9748d02.chunk.js
153 B build/static/js/75.954ccb1d.chunk.js
153 B build/static/js/625.5982bda3.chunk.js

The project was built assuming it is hosted at /.
You can control this with the homepage field in your package.json.

The build folder is ready to be deployed.
You may serve it with a static server:

npm install -g serve
serve -s build

Find out more about deployment here:

https://cra.link/deployment

✅ crawled 1 out of 6 (/)
✅ crawled 2 out of 6 (/404.html)
✅ crawled 3 out of 7 (/resume)
✅ crawled 4 out of 7 (/about)
✅ crawled 5 out of 7 (/projects)
🔥 error at /resume/resume: Error: Page crashed!
at Page._onTargetCrashed (/home/runner/work/cameronmackinnon.github.io/cameronmackinnon.github.io/node_modules/puppeteer/lib/Page.js:215:24)
at CDPSession. (/home/runner/work/cameronmackinnon.github.io/cameronmackinnon.github.io/node_modules/puppeteer/lib/Page.js:123:56)
at CDPSession.emit (node:events:517:28)
at CDPSession._onMessage (/home/runner/work/cameronmackinnon.github.io/cameronmackinnon.github.io/node_modules/puppeteer/lib/Connection.js:200:12)
at Connection._onMessage (/home/runner/work/cameronmackinnon.github.io/cameronmackinnon.github.io/node_modules/puppeteer/lib/Connection.js:112:17)
at WebSocket. (/home/runner/work/cameronmackinnon.github.io/cameronmackinnon.github.io/node_modules/puppeteer/lib/WebSocketTransport.js:44:24)
at WebSocket.onMessage (/home/runner/work/cameronmackinnon.github.io/cameronmackinnon.github.io/node_modules/puppeteer/node_modules/ws/lib/event-target.js:120:16)
at WebSocket.emit (node:events:517:28)
at Receiver.receiverOnMessage (/home/runner/work/cameronmackinnon.github.io/cameronmackinnon.github.io/node_modules/puppeteer/node_modules/ws/lib/websocket.js:789:20)
at Receiver.emit (node:events:517:28)
✅ crawled 6 out of 7 (/contact)

Error: Process completed with exit code 1.

[dosubot]

🤖

Hello @cameronmackinnon! 👋 I'm Dosu, a friendly bot here to assist you with bugs, queries, and contributions. While we wait for a human maintainer, feel free to ask me anything. I'm here to make your coding journey a bit smoother!

From the error logs you've provided, it seems like the issue is related to the react-snap package. The error Page crashed! is thrown by Puppeteer, which is a dependency of react-snap. This error usually occurs when the page being crawled by Puppeteer runs out of memory or encounters an unexpected error.

One possible solution could be to increase the memory limit for Node.js. You can do this by adding the --max_old_space_size flag to the predeploy script in your package.json file:

"predeploy": "node --max_old_space_size=4096 ./node_modules/.bin/react-scripts build && react-snap"

This will increase the memory limit to 4GB, which should be enough for most applications. If you're still encountering issues, you might need to increase the limit further.

As for the babel-preset-react-app warning, you can add "@babel/plugin-proposal-private-property-in-object" to your devDependencies to suppress the warning. However, this is just a warning and should not cause your build to fail.

Regarding the "failed to launch chrome" errors, this could be due to a lack of necessary dependencies in the environment where the build is running. Puppeteer requires certain packages to be installed in order to launch a headless Chrome instance. You can find a list of these packages in the Puppeteer troubleshooting guide.

Lastly, it would be helpful to know the exact versions of Node.js and npm being used in both your local and CI environments. This information can help in diagnosing the issue further. If you're not sure how to check these versions, you can do so by running node -v and npm -v in your terminal.

I hope this helps! If you have any other questions or need further clarification, feel free to ask.

-Dosu

Sources

• package.json

---

This response is meant to be useful and save you time. It is not meant to be a precise solution, but rather a starting point for your own research.

Help me be more useful! Please leave a 👍 if this is helpful and 👎 if it is irrelevant.

If you want to continue the conversation, start your reply with @dosu-bot.

[cameronmackinnon]

@dosu-bot, This sadly did not work. I tried changing it to that line before I run npm install as well as after having run npm install. I also tried changing "./node_modules/.bin/react-scripts" to "npm run". I also tried bumping it to 8192 and 16384.

On local, I am using node -v21.5.0 (but I have also tried with 16, 18, and 20 using nvm) and npm v 10.2.4.

The CI environment is using node v18.19 and npm 10.2.3. I printed these in the github-pages.yml file before running Checkout. I tried nvm use 18 in local to match the CI but still receiving the same errors.

On a potentially related note, the package-lock.json seems to be installing inconsistently, sometimes after running npm install it generates a package-lock file with ~30k lines of code, but other times it is only ~23k lines of code. I am deleting the node_modules and package-lock file along with running npm clear cache before retrying npm install.

Should I try to install and use yarn instead of npm?

[dosubot]

🤖

Switching to Yarn might indeed help resolve the inconsistent installation and build issues you're experiencing. Yarn is known for its deterministic installation process, which means it creates the same node_modules directory structure every time it's run. This can help avoid inconsistencies across different environments.

To switch to Yarn, you would need to change the cache: 'npm' to cache: 'yarn' and replace npm ci with yarn install --frozen-lockfile in your GitHub Actions workflow file. The --frozen-lockfile option ensures Yarn doesn't generate a yarn.lock file and only installs versions of dependencies that are already specified in the existing yarn.lock file.

Here's how your updated GitHub Actions workflow file might look:

# This workflow will do a clean install of node dependencies, build the source code and run tests across different versions of node
# For more information see: https://help.github.com/actions/language-and-framework-guides/using-nodejs-with-github-actions

name: Node.js CI

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]
  workflow_dispatch:

jobs:
  lint:
    runs-on: ${{ matrix.os }}
    timeout-minutes: 5
    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest, macos-latest]
    steps:
    - uses: actions/checkout@v4
    - uses: actions/setup-node@v3
      with:
        node-version-file: '.nvmrc'
        cache: 'yarn'
    - run: yarn install --frozen-lockfile
    - name: Lint
      run: yarn lint

  build:
    runs-on: ${{ matrix.os }}
    timeout-minutes: 10
    strategy:
      matrix:
        node-version: [16.x, 18.x, 20.x]
        os: [ubuntu-20.04, windows-latest, macos-latest]
        exclude:
          - os: windows-latest
            node-version: 16.x
          - os: windows-latest
            node-version: 18.x
          - os: macos-latest
            node-version: 16.x
          - os: macos-latest
            node-version: 18.x
    steps:
    - uses: actions/checkout@v4
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v3
      with:
        node-version: ${{ matrix.node-version }}
        cache: 'yarn'
    - run: yarn install --frozen-lockfile
    - name: Build and Statically Render
      run: yarn predeploy
      env:
        NODE_ENV: development
    - name: Test
      run: yarn test
      env:
        NODE_ENV: development

Please note that you would need to have a yarn.lock file in your repository for Yarn to work correctly. If you don't have one, you can generate it by running yarn install in your local environment.

As for the babel-preset-react-app package, the exact version being used in the project cannot be determined from the provided context. The package.json file does not list babel-preset-react-app in either the dependencies or devDependencies sections. However, it does list @babel/preset-react with version ^7.23.3. If you meant to ask about @babel/preset-react, then the version is 7.23.3.

I hope this helps! If you have any other questions or need further clarification, feel free to ask.

Sources

• .github/workflows/node.js.yml
• package.json

---

This response is meant to be useful and save you time. It is not meant to be a precise solution, but rather a starting point for your own research.

Help me be more useful! Please leave a 👍 if this is helpful and 👎 if it is irrelevant.

If you want to continue the conversation, start your reply with @dosu-bot.

[cameronmackinnon]

@dosubot, I switched to yarn and although it's working more often, it still fails inconsistently. I am confident it is a memory issue. I manually added puppeteer (yarn add puppeteer) to ensure that puppeteer is the latest version - this seems to be one of the main causes of the large memory: puppeteer has a large chromium file. (puppeteer/puppeteer#1321)

I have also tried the increase node size with yarn and it doesn't seem to make a difference. I am also deleting my caches in github actions, and occasionally restarting my computer/VS Code.

If you have any other suggestions as to how to deal with this memory issue, please let me know.

[dosubot]

🤖

I understand your frustration with the inconsistent build failures due to memory issues. It seems you've already tried increasing the memory limit for Node.js with the --max-old-space-size flag, but it didn't resolve the issue consistently.

Given that you've identified Puppeteer as a potential cause of the high memory usage, you might want to consider using puppeteer-core instead of puppeteer. puppeteer-core is a lighter version of Puppeteer that doesn't download Chromium by default, which could help reduce memory usage. You can install it using yarn with yarn add puppeteer-core.

Additionally, you can try to reduce the memory usage of your application by optimizing your code. This could involve removing unnecessary dependencies, reducing the size of your assets, or optimizing your React components. Tools like Webpack Bundle Analyzer can help you understand what's contributing to the size of your JavaScript bundles.

Regarding the inconsistent package-lock.json file, this could be due to differences in the npm versions used in your local environment and the CI environment. npm v7 introduced some changes to the package-lock.json format, which could explain the differences you're seeing. You might want to consider using the same npm version in both environments to ensure consistency.

Lastly, if you're still experiencing issues, it might be helpful to provide more information about your build process and the specific steps that are causing the memory issues. This could help identify other potential solutions.

Sources

• .github/workflows/node.js.yml
• package.json

---

This response is meant to be useful and save you time. It is not meant to be a precise solution, but rather a starting point for your own research.

Help me be more useful! Please leave a 👍 if this is helpful and 👎 if it is irrelevant.

If you want to continue the conversation, start your reply with @dosu-bot.

[atekumulla]

@cameronmackinnon I'm also having this issue but I'm not experienced in Node.js or Yarn. Have you figured out how to fix this issue? If yes, I'd love to hear the steps you took to change the original configuration so the npm build works.

[cameronmackinnon]

@atekumulla I'm pretty confident that it's a memory issue that doesn't have an easy fix. It's only the tests that are failing, but not the actual build, so I've been ignoring it for now as the published version seems to be working fine. The only ideas I had to increase capacity were purchasing more resources through git OR setting up a docker container that has more capacity. You could also turn off some of the tests (e.g., Windows 16.x), but this is more of a work-around than an actual fix.

I'm not experienced in nodejs or yarn either so take this with a grain of salt. Good luck!