Any plan to support ES6 style imports ?

[Xample]

My linter raises this error

suggestion:

instead of :

export = PGPubsub;
/** @typedef {(payload: any) => void} PGPubsubCallback */
declare class PGPubsub extends NodeJS.EventEmitter {

use

/** @typedef {(payload: any) => void} PGPubsubCallback */
export class PGPubsub extends NodeJS.EventEmitter {

same for

declare namespace PGPubsub {
    export { PGPubsubCallback };
}
type PGPubsubCallback = (payload: any) => void;

use

export type PGPubsubCallback = (payload: any) => void;

no need to add complex namespace and avoid using a global declare at all cost.
Usage will be
import {PGPubsub} from 'pg-pubsub'; Which is ES6 compliant

[voxpelli]

@Xample Importing CJS modules as if they were ESM modules should be supported in Node.js?

But yes, this module will likely receive the linemod treatment and be dual published eventually, but it shouldn't be a blocker.

Also: Why is your linter complaining about code from this module? Your linter should only check your own code?

[Xample]

@voxpelli, the error will of course appear in my code when I will need to use the "deprecated" require statement :-)

The linter suggests to replace to import PGPubsub from 'pg-pubsub';
but this will actually import the namespace which does not contains the PGPubsub class itself and therefore crash during the runtime.

To what I saw, this is due to the export = PGPubsub; instead of using export {PGPubsub} but the solution I gave above should be more ES6 friendly.

For now I keep using 'require' and disable the eslint error (because I did not find any other way to make it work with an import)

[voxpelli]

@Xample Can you share your tsconfig.json? Eg. have you set esModuleInterop?

[Xample]

I did not, and you are right enabling it should solve this import problem, but I want to avoid doing so as will break other dependencies of my project

{
  "compilerOptions": {
    "module": "commonjs",
    "declaration": true,
    "removeComments": true,
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "allowSyntheticDefaultImports": true,
    "target": "es2019",
    "sourceMap": true,
    "outDir": "./dist",
    "baseUrl": "./",
    "incremental": true,
    "lib": ["es2018", "dom", "esnext"]
  }
}

[voxpelli]

TypeScript really ought to once and for all move to esModuleInterop: microsoft/TypeScript#41139

Thanks for sharing! I'll keep this issue open to track making an ESM exports

[Xample]

it's interesting to see you opened this issue on TS a year ago :-)
and yes, the drawback is that enabling "esModuleInterop" or putting it to true as default is definitely a breaking change for some badly written packages. Thank you for your support