Cannot resolve module 'pg'

[udisun]

Edit @kamilogorek

This issue will now serve as a general thread for PG instrumentation discussion to keep the context in place.

Edit/update from project maintainers

Version 2.x does not have this problem; we recommend upgrading.

This issue remains open because the fix currently in 2.0 is sort of a bandaid, but if you aren't using the pg module anyway then the downside of the bandaid does not negatively affect you in any way. The long term fix will come in version 2.1.

Original comment below:

---

as of version 1.1.0 you have added an inline require('pg') on line 132 of raven/lib/breadcrumbs.js this should be a dependency in package.json. the error:

ERROR in ./~/raven/lib/breadcrumbs.js
Module not found: Error: Cannot resolve module 'pg' in project_dir/node_modules/raven/lib
 @ ./~/raven/lib/breadcrumbs.js 132:13-26

[LewisJEllis]

Where do you run into this error? Do you have a snippet I can run to reproduce it? We don't depend on/require pg, we just look to see if the project using raven-node is using pg themselves and, if so, instrument the pg module to capture breadcrumbs. The line you point to should only ever run inside a try/catch (here), so I wouldn't expect the error to escape.

[holmari]

This happens when you build with webpack. Something like this helps, in webpack.config.js:

module.exports = {
  ...
  externals: [
    {pg: true}
  ]
  node: {
    fs: 'empty'
  }
  ...
};

[LewisJEllis]

Ah, okay, that makes sense. I didn't really think about webpack in the Node case, but there are some legitimate uses, so it would probably be better here to check for the presence of the module using require.resolve rather than just attempting to load it. I'm guessing that'll make webpack quit looking for it when it's not there, but I'll have to verify.

[shubhamarora]

@LewisJEllis I am facing the same problem and there is no such pg param in my webpack config. Do we have any solution for this?

[benvinegar]

@shubhamarora – are you building your js files somehow? like, with Webpack + Babel? And are you intending to use raven-node or raven-js (browser JavaScript)?

[shubhamarora]

@benvinegar Yes, I am building/bundling using Weback + Babel and I am using raven-node.

[colinblaise]

Same issue for me as well. I am bundling raven-node with Webpack for use in the browser.

[mattrobenolt]

I am bundling raven-node with Webpack for use in the browser.

You shouldn't be using raven-node for that. raven-node will not run in a browser and you must use raven-js.

[LewisJEllis]

Earlier investigation didn't get anywhere - it wasn't as easy to juke webpack as I thought it might be - but I took a deeper dive into this today and found that we should be able to solve this by hooking into Module._load to instrument modules on the fly instead of trying each one ahead of time. Then pg for example will only be loaded if the user's application loads it, and webpack won't go trying to bundle it when it's not used.

I'm also going to add a check for browser-y globals like window, document, navigator, etc that will spit out a warning message ("hey you might want raven-js instead...") to try to reduce the number of users who mistakenly use raven-node when they want raven-js.

[colinblaise]

I gave up and installed raven-js with bower. I was already passing my bower-components to the client with webpack, so it worked immediately. Only downside is I have both raven-js and raven-node installed to handle both server and client.

On Tue, Feb 21, 2017 at 9:09 PM, Lewis J Ellis [email protected] wrote:

Earlier investigation didn't get anywhere - it wasn't as easy to juke webpack as I thought it might be - but I took a deeper dive into this today and found that we should be able to solve this by hooking into Module._load to instrument modules on the fly instead of ahead of time. Then pg for example will only be loaded if the user's application loads it, and webpack won't go trying to bundle it when it's not used.

I'm also going to add a check for browser-y globals like window, document, navigator, etc that will spit out a warning message ("hey you might want raven-js instead...") to try to reduce the number of users who mistakenly use raven-node when they want raven-js.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/getsentry/raven-node/issues/254#issuecomment-281555668, or mute the thread https://github.com/notifications/unsubscribe-auth/AGPL5hp4hJmmYCtD2N1NkO1NOuoIoSnTks5re6bbgaJpZM4LYrBg .

[shubhamarora]

@mattrobenolt - That is being used on the server side (Nodejs) code. Which is not on a target/dependency of Webpack bundling.

[shubhamarora]

Not getting this issue now in my case. Seems like somehow this dependency ( require('raven') ) was coming on webpack dependency tree due to which it was throwing that error (Maybe).

[maxbeatty]

I came across this today trying to bundle an AWS Lambda function using webpack and worked around it by declaring it in externals as mentioned above

[rodolfo3]

Same here:

    ERROR in ./~/raven/lib/breadcrumbs.js
    Module not found: Error: Can't resolve 'pg' in '/home/rodolfo/eduk/react/eduk-web-ui/node_modules/raven/lib'
     @ ./~/raven/lib/breadcrumbs.js 120:13-26
     @ ./~/raven/lib/client.js
     @ ./~/raven/index.js

Adding the externals conf fix it, but I think there is not right (pg is not used and does not exist).

Is there any other solution? Is this a problem from webpack or node-raven?

[LewisJEllis]

It's an issue with raven-node requireing pg to check if we should instrument it for autobreadcrumbs. If pg is not present, we don't load it, but webpack can't know that we're only checking for it opportunistically, so it tries to include it in bundling when it's not there/needed. Raven is being eager where it should be lazy; the fix is to instead hook into require itself and do instrumentation lazily whenever a module that should be instrumented is first used. I've done some work on that in this branch and plan to finish it soon.

[ffxsam]

This is a bit frustrating. I'm trying to use this with Meteor which also gives a warning about pg not being installed. I tried installing it, that worked, and then it needed pg-native which fails to build on my Mac for some reason.

gyp WARN download NVM_NODEJS_ORG_MIRROR is deprecated and will be removed in node-gyp v4, please use NODEJS_ORG_MIRROR
/bin/sh: pg_config: command not found
gyp: Call to 'pg_config --libdir' returned exit status 127 while in binding.gyp. while trying to load binding.gyp
gyp ERR! configure error
gyp ERR! stack Error: `gyp` failed with exit code: 1
gyp ERR! stack     at ChildProcess.onCpExit (/Users/samh/.meteor/packages/meteor-tool/.1.4.4_1.1ygrsyx++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/node-gyp/lib/configure.js:336:16)
gyp ERR! stack     at emitTwo (events.js:87:13)
gyp ERR! stack     at ChildProcess.emit (events.js:172:7)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:211:12)

But I'd rather not bloat my node_modules with unnecessary packages.

[cveilleux]

I am forced to stick to 1.0.0 release because of this issue.

[ffxsam]

@cveilleux Good to know this wasn't an issue in 1.0.0. I may roll back to that. Are we missing any important functionality by going back to that version?

[LewisJEllis]

I realized thanks to @cveilleux's comment that, if we can get away with it, simply removing the pg autobreadcrumb instrumentation will help. Since a major version (2.0.0 ref #314) is going out anyway, we can get away with it, and so I've removed pg instrumentation in #315 and that has gone out in version 2.0.0 which is live.

So: Use raven-node 2.0+ and you won't have this problem.

You also won't have autobreadcrumbs for your postgres queries, but obviously nobody in this thread was concerned about that. postgres autobreadcrumb instrumentation will return when the long-term fix for this issue is done, which as mentioned previously will be hooking require() to do reactive lazy instrumentation, instead of the proactive eager instrumentation that messes up with webpack.

[cveilleux]

I think it depends on how much magic you want the module to have, but another and simpler approach would be to have opt-in configuration flags in the Raven.config call.

special instrumentation could be enabled with extra flags for pg and eventually mysql, mongo, etc, etc..

[ffxsam]

Thanks for the awesome work, @LewisJEllis !

[LewisJEllis]

That's kinda how it already works, but yea in general we want as much magic as possible for when we eventually enable autobreadcrumbs by default. Autobreadcrumbs are currently off-by-default with opt-in config (docs here) for each breadcrumb type, pg being one of them. So to turn pg breadcrumbs on (in 1.x) you have to do:

Raven.config({
  autoBreadcrumbs: {
    pg: true
  }
}).install();

But simply not doing this doesn't avoid the issue at hand. The problem is that the function that ultimately runs when that flag is set does a require('pg'), and webpack can't magically figure out ahead of time whether that ever actually runs, so it's going to try to bundle pg just in case. I'm not sure what kind of boolean config flags could get around this.

The config pattern tweak that could work and still allow pg autobreadcrumbs without other changes would be if the relevant require call happened in relation to the config, e.g. something like:

Raven.config({
  autoBreadcrumbs: {
    pg: require('pg') // or, say, require('raven/breadcrumbs/pg') and that file does require('pg')
  }
}).install();

but that's kind of obtuse, not as user-friendly, would break consistency with our browser JS sdk, and won't work when we get to the point where autoBreadcrumbs are enabled by default.

Anyway, the real fix is next up and will come soon enough :)