Missing module './build' when building MTAR for SAP CAP using PostgreSQL DB

[renejurmann]

Hi experts,

we have created a SAP CAP Node.JS project using a PostgreSQL database and CDS 7+. Up to last week all was perfectly working fine. But since yesterday we face an issue with running "cds build" (or "mbt build") commands. We now get following error:

INFO executing the "npx cds build --production" command...
....Error: Cannot find module './build'
Require stack:
- C:\...\our-cap-postgre\node_modules\@cap-js\postgres\cds-plugin.js
- C:\...\our-cap-postgre\node_modules\@sap\cds\lib\plugins.js
- C:\...\our-cap-postgre\node_modules\@sap\cds\lib\index.js
- C:\...\our-cap-postgre\node_modules\@sap\cds-dk\lib\cds.js
- C:\...\our-cap-postgre\node_modules\@sap\cds-dk\bin\cds.js
    at Module._resolveFilename (node:internal/modules/cjs/loader:1077:15)
    at Module._load (node:internal/modules/cjs/loader:922:27)
    at Module.require (node:internal/modules/cjs/loader:1143:19)
    at require (node:internal/modules/cjs/helpers:110:18)
    at Object.<anonymous> (C:\...\our-cap-postgre\node_modules\@cap-js\postgres\cds-plugin.js:8:20)
    at Module._compile (node:internal/modules/cjs/loader:1256:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1310:10)
    at Module.load (node:internal/modules/cjs/loader:1119:32)
    at Module._load (node:internal/modules/cjs/loader:960:12)
    at Module.require (node:internal/modules/cjs/loader:1143:19) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
    'C:\\...\our-cap-postgre\\node_modules\\@cap-js\\postgres\\cds-plugin.js',
    'C:\\...\our-cap-postgre\\node_modules\\@sap\\cds\\lib\\plugins.js',
    'C:\\...\our-cap-postgre\\node_modules\\@sap\\cds\\lib\\index.js',
    'C:\\...\our-cap-postgre\\node_modules\\@sap\\cds-dk\\lib\\cds.js',
    'C:\\...\our-cap-postgre\\node_modules\\@sap\\cds-dk\\bin\\cds.js'
  ]
}
[2023-10-10 07:53:51] ERROR the "before-all"" build failed: could not execute the "npx cds build --production" command: exit status 1
make: *** [Makefile_20231010075251.mta:28: pre_build] Error 1
Error: could not build the MTA project: could not execute the "make -f Makefile_20231010075251.mta p=cf mtar= strict=true mode=" command: exit status 2

As we always delete the node_modules folder after we finished working, the npm install command always fetches the according npm pacakages before running the cds build command. But it seems as if since yesterday the "@cap-js\postgres" seems to be corrupt. Or is there anything else we miss?

Out package.json looks as follows:

{
  "name": "our-cap-postgre",
  "version": "3.1.0",
  "description": "A CAP project using PostgreSQL DB holding the CDS",
  "repository": "<Add your repository here>",
  "license": "ISC",
  "private": true,
  "dependencies": {
    "@cap-js-community/odata-v2-adapter": "^1.11.7",
    "@cap-js/postgres": "^1.3.0",
    "@sap-cloud-sdk/http-client": "^3.6.0",
    "@sap-cloud-sdk/resilience": "^3.6.0",
    "@sap/cds": "~7.3.0",
    "@sap/cds-dk": "^7.3.0",
    "@sap/xsenv": "^4.0.0",
    "@sap/xssec": "^3.3.5",
    "passport": "^0.6.0"
  },
  "scripts": {
    "start": "npx cds run",
    "start:docker": "docker-compose build && docker-compose up -d",
    "update:docker": "docker-compose pull && docker-compose up -d",
    "test:local": "cds watch",
    "test:hybrid": "cds watch --profile hybrid",
    "build:local": "cds build",
    "deploy:local": "cds deploy --auto-undeploy",
    "build:cf": "mbt build",
    "deploy:cf": "cf deploy mta_archives/our-cap-postgre_3.1.0.mtar --retries 0",
    "build:deploy:cf": "mbt build && cf deploy mta_archives/our-cap-postgre_3.1.0.mtar --retries 0",
    "undeploy:cf": "cf undeploy our-cap-postgre --delete-service-brokers --delete-service-keys --delete-services"
  },
  "cds": {
    "requires": {
      "db": {
        "kind": "postgres",
        "impl": "@cap-js/postgres",
        "dialect": "postgres",
        "schema_evolution": "auto",
        "pool": {
          "acquireTimeoutMillis": 5000,
          "evictionRunIntervalMillis": 2000,
          "numTestsPerEvictionRun": 20,
          "softIdleTimeoutMillis": 3000,
          "min": 0,
          "max": 500,
          "fifo": true
        }
      },
      "[production]": {
        "uaa": {
          "kind": "xsuaa"
        }
      },
      "auth": {
        "users": {
          "bob": {
            "roles": [
              "Admin",
              "CommunityMember"
            ]
          },
          "alice": {
            "roles": [
              "Admin",
              "CommunityMember"
            ]
          },
          "carol": {
            "roles": [
              "CommunityMember"
            ]
          },
          "dave": {
            "roles": [
              "CommunityMember"
            ]
          }
        }
      }
    },
    "cov2ap": {
      "plugin": true
    },
    "migrations": {
      "db": {
        "schema": {
          "default": "public",
          "clone": "_cdsdbm_clone",
          "reference": "_cdsdbm_ref"
        },
        "deploy": {
          "tmpFile": "tmp/_autodeploy.json",
          "undeployFile": "db/undeploy.json"
        }
      }
    }
  }
}

regards

René

[renejurmann]

Issue is fixed with version 1.3.1 of npm package @cap-js/postgres

[Willem_Pardaens]

Hi René,

I see you already opened a Bug report on the git repository. That is good and will be the best way to get this resolved. In the meantime, you can try and put your dependency back to v1.2.1 to use the previous release. Using a package-lock.json file would prevent these things from happening, as it puts you in control of when you want to test package upgrades (1.2.1 -> 1.3.0) as opposed to testing your own application and keeping dependencies stable.

[renejurmann]

We already faced the issue with version 1.2.1 which was curious as we had not changed anything in package-json... I then just saw that there is an update to the postgres and cds package and tried the same with the up-to-date version. But the issue was the same.

However, in the meantime they have fixed the bug and all is working fine again.

[Willem_Pardaens]

Interesting.. thanks for the feedback. Great they managed to resolve it.