fix(pg): fix instrumentation of ESM-imported pg

[trentm]

The ESM imported top-level object is a Module Namespace Object per ECMA262 spec that is, apparently, incompatible with the 'PG' class object that 'pg' returns. The ".defaults" holds the equivalent of require('pg').

Fixes: #1693

---

This is a similar fix to #1694. See the discussion there on the use of module[Symbol.toStringTag] === 'Module' to sniff out ESM.

A dump of moduleExports before this change, when loading pg as ESM is as follows. This shows how the PG instance export is replaced with the [Module: null prototype] and how .default holds the top-level CommonJS exports.

[Module: null prototype] {
  default: PG {
    defaults: {
      host: 'localhost',
      user: 'trentm',
      database: undefined,
      password: null,
      connectionString: undefined,
      port: 5432,
      rows: 0,
      binary: false,
      max: 10,
      idleTimeoutMillis: 30000,
      client_encoding: '',
      ssl: false,
      application_name: undefined,
      fallback_application_name: undefined,
      options: undefined,
      parseInputDatesAsUTC: false,
      statement_timeout: false,
      idle_in_transaction_session_timeout: false,
      query_timeout: false,
      connect_timeout: 0,
      keepalives: 1,
      keepalives_idle: 0,
      parseInt8: [Setter]
    },
    Client: [class Client extends EventEmitter] {
      Query: [class Query extends EventEmitter]
    },
    Query: [class Query extends EventEmitter],
    Pool: [class BoundPool extends Pool],
    _pools: [],
    Connection: [class Connection extends EventEmitter],
    types: {
      getTypeParser: [Function: getTypeParser],
      setTypeParser: [Function: setTypeParser],
      arrayParser: [Object],
      builtins: [Object]
    },
    DatabaseError: [class DatabaseError extends Error]
  }
}

Checklist

• Decide whether and how to add a test case for this. I could add a separate npm run test:esm. The downside of that is that the npm run test:local version of this will stop and start a Postgres instance once for CommonJS tests (*.test.js) and then once again for ESM tests (*.test.mjs).
• Deal with TypeScript-related lint errors.

[codecov]

Codecov Report

Merging #1701 (7246328) into main (7b457cd) will decrease coverage by 0.05%.
The diff coverage is 44.44%.

@@            Coverage Diff             @@
##             main    #1701      +/-   ##
==========================================
- Coverage   91.67%   91.62%   -0.05%     
==========================================
  Files         139      139              
  Lines        7145     7151       +6     
  Branches     1440     1444       +4     
==========================================
+ Hits         6550     6552       +2     
- Misses        595      599       +4     

Files	Coverage Δ
...elemetry-instrumentation-pg/src/instrumentation.ts	88.96% <44.44%> (-2.26%)	⬇️

[trentm]

• Deal with TypeScript-related lint errors.

Oh, lint passes. There are a number of warnings from npm run lint, but I guess those are okay. Most of those warnings existed before my change.

[pichlermarc]

Decide whether and how to add a test case for this. I could add a separate npm run test:esm. The downside of that is that the npm run test:local version of this will stop and start a Postgres instance once for CommonJS tests (.test.js) and then once again for ESM tests (.test.mjs).

I would consider this an acceptable trade-off for testing this. 👍
We could also add more scripts for local testing: test:local:cjs, test:local:esm that are both run by test:local - this way one can test both individually when working on the package. I think the important part would be to have the ESM tests run in the unit-testing and TAV workflows.

Edit: created #1731 to come up with a testing strategy for ESM - we'll need this going forward

[pichlermarc]

Thanks for taking care of this! 🙂