What is the NodeJS ES6 equivalent of let PouchDB = require(‘pouchdb’)?

I am trying to follow the tutorial at https://medium.com/beginners-guide-to-mobile-web-development/getting-started-with-pouchdb-f0f3d7baebab to use PouchDB inside of a server-side NodeJS script.

and I’m getting stuck in Step 1:

const PouchDB = require('pouchdb');

this results in:

ReferenceError: require is not defined in ES module scope, you can use import instead

When I google the error, I am told to change "type":"module" to "type":"commonjs".

Unfortunately, I cannot do that because it breaks another part of the script where I’m already using an ES6 import.

Is there a way to rewrite this require statement so that it works in NodeJS ES6?

HERE’S SOME OF WHAT I HAVE TRIED SO FAR

I have found tons of related questions but none appear to address the pouchdb module specifically, and unfortunately I don’t know javascript well enough to be able to generalize and extrapolate from the generic advice found to the very specific fix I need.

For example, this question: ES6 equivalent of require(‘module’).function() advises using import { foobar as Foobar } from 'module';

But when I translate that to import { PouchDB } from 'pouchdb'; then I get this:

SyntaxError: Named export ‘PouchDB’ not found. The requested module ‘pouchdb’ is a CommonJS module, which may not support all module.exports as named exports. CommonJS modules can always be imported via the default export, for example using:

import pkg from ‘pouchdb’; const { PouchDB } = pkg;

And when I try to follow the advice from the above error message and use import pkg from 'pouchdb'; const { PouchDB } = pkg;, then I get this:

TypeError: PouchDB is not a constructor

TL;DR I need to know how to implement a simple require() statement in ES6 when reverting back to CommonJS is not possible because other stuff in the same script is already using ES6 imports.

UPDATE

Here is the output of import * as pDB from 'pouchdb'; console.log(pDB, typeof pDB);:

[Module: null prototype] {
  default: [Function: PouchDB] {
    adapters: { leveldb: [Function], http: [Function], https: [Function] },
    preferredAdapters: [ 'leveldb' ],
    prefix: '_pouch_',
    setMaxListeners: [Function: bound setMaxListeners],
    getMaxListeners: [Function: bound getMaxListeners],
    emit: [Function: bound emit],
    addListener: [Function: bound addListener],
    on: [Function: bound addListener],
    prependListener: [Function: bound prependListener],
    once: [Function: bound once],
    prependOnceListener: [Function: bound prependOnceListener],
    removeListener: [Function: bound removeListener],
    off: [Function: bound removeListener],
    removeAllListeners: [Function: bound removeAllListeners],
    listeners: [Function: bound listeners],
    rawListeners: [Function: bound rawListeners],
    listenerCount: [Function: bound listenerCount],
    eventNames: [Function: bound eventNames],
    _destructionListeners: Map(0) {},
    adapter: [Function (anonymous)],
    plugin: [Function (anonymous)],
    defaults: [Function (anonymous)],
    fetch: [Function (anonymous)],
    _changesFilterPlugin: {
      validate: [Function: validate],
      normalize: [Function: normalize],
      shouldFilter: [Function: shouldFilter],
      filter: [Function: filter]
    },
    version: '7.3.1',
    replicate: [Function: replicateWrapper],
    sync: [Function: sync]
  }
} object

Answer

Without getting in to too much detail, there’s no simple mapping between the old CJS module.exports and the new ESM import/export (if there were the tools could handle it automatically, and you wouldn’t have had to ask this question).

ESM makes a very clear syntactic distinction between the default export and named exports, there is no strict equivalent in the CJS scheme.

import PouchDB from 'pouchdb';

Will give you the default export of the module, which is what you want. When troubleshooting these kinds of problems you can always do a star import:

import * as Whatever from 'some-package';

Which will give you a pseudo object whose properties are all the exports of the package which you can then introspect on to find the thing you want. Note that you don’t want to do that star import for client side code in production as it defeats a lot of unused code-elimination analysis for reducing bundle sizes, but it is useful for troubleshooting in development.

Advertisement

Answer