Tests failing on lts/*

[bcomnes]

Tests need some love on lts/*.

[erkobridee]

I give a try with the v16 LTS, but it didn't work 😢

on the following project:
https://github.com/erkobridee/nextjs-ssg

when I tried to execute npm build, that executes the script command: npx run-s clean next:build

I got the following error:

➜  nextjs-ssg git:(update/nodejs-v16) ✗ npm run build

> nextjs-ssg@4.9.1 build
> npx run-s clean next:build

Watching /machine-path/github/erkobridee/nextjs-ssg and all sub-directories not excluded by your .gitignore. Will not monitor dotfiles.
Found & ignored ./.husky ; is listed in .gitignore
Found & ignored ./node_modules ; is listed in .gitignore

Starting: clean
node:internal/modules/cjs/loader:936
  throw err;
  ^

Error: Cannot find module '/machine-path/github/erkobridee/nextjs-ssg/clean'
    at Function.Module._resolveFilename (node:internal/modules/cjs/loader:933:15)
    at Function.Module._load (node:internal/modules/cjs/loader:778:27)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:77:12)
    at node:internal/main/run_main_module:17:47 {
  code: 'MODULE_NOT_FOUND',
  requireStack: []

environment:

➜  nextjs-ssg git:(update/nodejs-v16) ✗ node -v
v16.15.1

➜  nextjs-ssg git:(update/nodejs-v16) ✗ npm -v
8.11.0

➜  nextjs-ssg git:(update/nodejs-v16) ✗ system_profiler SPSoftwareDataType SPHardwareDataType
Software:

    System Software Overview:

      System Version: macOS 12.3.1 (21E258)
      Kernel Version: Darwin 21.4.0
      Boot Volume: Macintosh HD
      Boot Mode: Normal
      Computer Name: {hidded}
      User Name: {hidded}
      Secure Virtual Memory: Enabled
      System Integrity Protection: Enabled
      Time since boot: 24 days 17:25

Hardware:

    Hardware Overview:

      Model Name: MacBook Pro
      Model Identifier: MacBookPro18,2
      Chip: Apple M1 Max
      Total Number of Cores: 10 (8 performance and 2 efficiency)
      Memory: 32 GB
      System Firmware Version: 7459.101.3
      OS Loader Version: 7459.101.3
      Serial Number (system): {hidded}
      Hardware UUID: {hidded}
      Provisioning UDID: {hidded}
      Activation Lock Status: Enabled

ps.: previously I was using the node.js v14 LTS, which works fine

[bcomnes]

I wonder if it has to do with running npx inside of a script field. That shouldn't be necessary as devDependencies are made available in the PATH when running in the script field context. But it does sound related due to the issue being triggered by changing versions of node/npm.

[bcomnes]

EDIT nevernmind.

[bcomnes]

Ok I played around with your project a little bit. A couple notes:

• You should remove the extraneous npx invocations, they really just confuse everything and might be contributing to issues.
• Running npx run-s seems to be having issues. I'm not sure what the issue is, but the work around is to just not-do-that.

{
  "name": "nextjs-ssg",
  "version": "4.9.1",
  "private": true,
  "scripts": {
    "husky:uninstall": "rimraf .husky && git config --unset core.hooksPath",
    "husky:install": "husky install",
    "husky:config:pre-commit": "husky add .husky/pre-commit \"lint-staged\"",
    "husky": "node scripts/husky-setup.js",
    "prepare": "is-ci || run-s husky:install husky:config:pre-commit",
    "prettify": "prettier --write .",
    "check:lint": "eslint 'src/**/*.{js,jsx,ts,tsx}'",
    "check:typescript": "tsc --noEmit",
    "check": "run-s prettify check:lint check:typescript",
    "next:dev": "next dev",
    "next:export": "next export",
    "next:build": "next build",
    "next:start": "next start",
    "post:next:export": "node scripts/post-export.js",
    "start": "run-s next:dev",
    "clean:node_modules-cache": "rimraf node_modules/.cache",
    "clean:next-cache": "rimraf .next",
    "clean:next-output": "rimraf out",
    "clean": "run-p clean:node_modules-cache clean:next-cache clean:next-output",
    "build:ci": "run-s clean next:build next:export post:next:export",
    "build": "run-s clean next:build",
    "serve-nextjs-output": "serve out -l 3000",
    "serve": "run-s build next:start",
    "serve:ci": "cross-env NODE_ENV=local run-s build:ci serve-nextjs-output",
    "predeploy:gh-pages": "touch out/.nojekyll",
    "deploy:gh-pages": "gh-pages -d out --dotfiles",
    "deploy": "run-s build:ci deploy:gh-pages",
    "ci": "cross-env NODE_ENV=production run-s build:ci",
    "pullrequest": "run-s check build",
    "bundle-analyze": "cross-env ANALYZE=true run-s clean next:build"
  },
  "lint-staged": {
    "src/**/*.{js,jsx,ts,tsx,md,html,css,scss}": "prettier --write",
    "src/**/*.{js,jsx,ts,tsx}": "eslint --fix"
  },
  "dependencies": {
    "clsx": "1.1.1",
    "i18next": "21.6.14",
    "i18next-browser-languagedetector": "6.1.4",
    "next": "12.1.2",
    "react": "17.0.2",
    "react-dom": "17.0.2",
    "react-i18next": "11.16.2"
  },
  "devDependencies": {
    "@next/bundle-analyzer": "12.1.2",
    "@next/eslint-plugin-next": "12.1.2",
    "@types/node": "17.0.21",
    "@types/react": "17.0.45",
    "@typescript-eslint/eslint-plugin": "5.15.0",
    "@typescript-eslint/parser": "5.15.0",
    "autoprefixer": "10.4.7",
    "cross-env": "7.0.3",
    "eslint": "8.11.0",
    "eslint-config-next": "12.1.2",
    "eslint-config-prettier": "8.5.0",
    "eslint-plugin-prettier": "4.0.0",
    "eslint-plugin-react": "7.29.4",
    "eslint-plugin-tailwindcss": "3.5.0",
    "gh-pages": "3.2.3",
    "husky": "7.0.4",
    "is-ci": "3.0.1",
    "lint-staged": "12.3.7",
    "npm-run-all2": "5.0.2",
    "postcss": "8.4.14",
    "postcss-import": "14.1.0",
    "prettier": "2.6.2",
    "prettier-plugin-tailwindcss": "0.1.8",
    "rimraf": "3.0.2",
    "sass": "1.52.3",
    "serve": "13.0.2",
    "tailwindcss": "3.0.24",
    "typescript": "4.6.2"
  }
}

This works, and avoids the unessisary call out to that node script where its just shells out to an npx call.

If someone wants to look into why npx run-s isn't working right, I'm open to PRs, but I don't have the bandwidth to fix that right now. Generally npm-run-all is designed to be run in npm script fields, and running it outside of that context or wrappers like npx might break assumptions it has.

[erkobridee]

@bcomnes thanks for the feedback o/

a bit of context of why I used the npx run-s , I got an issue when I was running the build flow at the MS Azure Pipeline with Node.js v14 on top of Ubuntu v20, where when I called a script that had only run-s ... it didn't work

the npx command on the node.js v14 worked like an alias into the local /node_modules/.bin where it's placed the script run-s, and that solved my issue in that case

so I suspect that the npx changed between the node.js v14 and the v16 and that behavior didn't work anymore

[erkobridee]

@bcomnes just to keep you posted, I followed up on your tip and that fixed my issue, and at least the build also worked at the GitHub pipeline 😄

my own PR to move forward to node.js v16
erkobridee/nextjs-ssg#213

the pipelines executions

pull request validation
https://github.com/erkobridee/nextjs-ssg/runs/6838827796?check_suite_focus=true

build and deploy to GitHub pages
https://github.com/erkobridee/nextjs-ssg/runs/6838845941?check_suite_focus=true

[bcomnes]

Cool, glad that worked. npm and npx can change in weird ways over time.