Cannot find module 'pg-native'

[emahuni]

I have seen this error many times when my app errs for some reason or another as long as there is data that has something to do with the knex or bookshelf module. Other modules in this case have nothing to do with this per se as the source for this library clearly requires pg-native, but doesn't declare it in its package.json anywhere. Here is stack trace and source where it is being required.

Stack trace:

Cannot find module 'pg-native'
Require stack:
- /home/em/project/api/node_modules/pg/lib/native/client.js
- /home/em/project/api/node_modules/pg/lib/native/index.js
- /home/em/project/api/node_modules/pg/lib/index.js
- /home/em/project/api/node_modules/strapi-connector-bookshelf/lib/knex.js
- /home/em/project/api/node_modules/strapi-connector-bookshelf/lib/index.js
- /home/em/project/api/node_modules/strapi-database/lib/require-connector.js
- /home/em/project/api/node_modules/strapi-database/lib/database-manager.js
- /home/em/project/api/node_modules/strapi-database/lib/index.js
- /home/em/project/api/node_modules/strapi/lib/Strapi.js
- /home/em/project/api/node_modules/strapi/lib/index.js
- /home/em/project/api/node_modules/strapi/lib/commands/develop.js
- /home/em/project/api/node_modules/strapi/bin/strapi.js

Source referred to by top-most (throwing) line from this module:

cat /home/em/project/api/node_modules/pg/lib/native/client.js
'use strict'
/**
 * Copyright (c) 2010-2017 Brian Carlson (brian.m.carlson@gmail.com)
 * All rights reserved.
 *
 * This source code is licensed under the MIT license found in the
 * README.md file in the root directory of this source tree.
 */

// eslint-disable-next-line
var Native = require('pg-native')

The supposed eslint error and warning is disabled showing this maybe desired, but is causing errors upstream.

Here is the package.json dependency section for this module:

"dependencies": {
    "buffer-writer": "2.0.0",
    "packet-reader": "1.0.0",
    "pg-connection-string": "0.1.3",
    "pg-packet-stream": "^1.1.0",
    "pg-pool": "^2.0.10",
    "pg-types": "^2.1.0",
    "pgpass": "1.x",
    "semver": "4.3.2"
  },
  "devDependencies": {
    "async": "0.9.0",
    "bluebird": "3.5.2",
    "co": "4.6.0",
    "eslint": "^6.0.1",
    "eslint-config-standard": "^13.0.1",
    "eslint-plugin-import": "^2.18.1",
    "eslint-plugin-node": "^9.1.0",
    "eslint-plugin-promise": "^4.2.1",
    "eslint-plugin-standard": "^4.0.0",
    "pg-copy-streams": "0.3.0"
  },

Can/should this be corrected in this module by adding pg-native in dependancies?

[brianc]

pg-native is not a dependency unless you "opt in" to it by accessing pg.native. If it's installed and you access pg.native in your code it will dynamically require it. This way you can use pg in environments where you don't have a compiler or don't want the native bindings. If you don't have pg-native installed it will error at the point you call pg.native I could experiment with making it an optional dependency but I'm not super concerned with it right now. What version of pg do you have installed? There was a bug in versions prior to pg@8.x where if you enumerated the pg object in any way (console.log(pg) for example) it would enumerate the pg.native getter, require the module, and often crash if it was missing. Steps were taken to mitigate this here

[marcoippolito]

I "solved" adding three mock dependencies:

package.json :

"dependencies": {
    "dns": "file:./src/mock/dns",
    "fs": "file:./src/mock/fs",
    "net": "file:./src/mock/net",
    "pg-native": "file:./src/mock/pg-native",

/src/mock$ ls -lah
total 24K
drwxr-xr-x 6 marco marco 4,0K apr 19 11:37 .
drwxrwxr-x 7 marco marco 4,0K apr 19 11:07 ..
drwxr-xr-x 2 marco marco 4,0K apr  4 18:40 dns
drwxr-xr-x 2 marco marco 4,0K apr  4 17:33 fs
drwxr-xr-x 2 marco marco 4,0K apr  4 18:44 net
drwxr-xr-x 2 marco marco 4,0K apr 19 11:37 pg-native

/src/mock/pg-native$ ls -lah
total 16K
drwxr-xr-x 2 marco marco 4,0K apr 19 11:37 .
drwxr-xr-x 6 marco marco 4,0K apr 19 11:37 ..
-rw-r--r-- 1 marco marco   51 apr  4 17:20 index.js
-rw-r--r-- 1 marco marco   71 apr 19 11:37 package.json

nano index.js :

module.exports = {}; 
module.exports.default = {};

nano package.json :

{ 
  "name": "pg-native", 
  "version": "3.1.0", 
  "private": true 
}

@brianc Is there a better way to solve this problem?

[emahuni]

pg-native is not a dependency unless you "opt in" to it by accessing pg.native. If it's installed and you access pg.native in your code it will dynamically require it. This way you can use pg in environments where you don't have a compiler or don't want the native bindings. If you don't have pg-native installed it will error at the point you call pg.native I could experiment with making it an optional dependency but I'm not super concerned with it right now. What version of pg do you have installed? There was a bug in versions prior to pg@8.x where if you enumerated the pg object in any way (console.log(pg) for example) it would enumerate the pg.native getter, require the module, and often crash if it was missing. Steps were taken to mitigate this here

I am running PG 11.

So putting it in package.json will cause a crash?

[emahuni]

I "solved" adding three mock dependencies:

package.json :

"dependencies": {
    "dns": "file:./src/mock/dns",
    "fs": "file:./src/mock/fs",
    "net": "file:./src/mock/net",
    "pg-native": "file:./src/mock/pg-native",

/src/mock$ ls -lah
total 24K
drwxr-xr-x 6 marco marco 4,0K apr 19 11:37 .
drwxrwxr-x 7 marco marco 4,0K apr 19 11:07 ..
drwxr-xr-x 2 marco marco 4,0K apr  4 18:40 dns
drwxr-xr-x 2 marco marco 4,0K apr  4 17:33 fs
drwxr-xr-x 2 marco marco 4,0K apr  4 18:44 net
drwxr-xr-x 2 marco marco 4,0K apr 19 11:37 pg-native

/src/mock/pg-native$ ls -lah
total 16K
drwxr-xr-x 2 marco marco 4,0K apr 19 11:37 .
drwxr-xr-x 6 marco marco 4,0K apr 19 11:37 ..
-rw-r--r-- 1 marco marco   51 apr  4 17:20 index.js
-rw-r--r-- 1 marco marco   71 apr 19 11:37 package.json

nano index.js :

module.exports = {}; 
module.exports.default = {};

nano package.json :

{ 
  "name": "pg-native", 
  "version": "3.1.0", 
  "private": true 
}

@brianc Is there a better way to solve this problem?

doesn't this cause a problem since it is required when the lib needs real access to the native lib like Brian is saying?