Make winston more ESM friendly

[miguelcobain]

This PR should make winston friendlier to ESM module named exports.

Basically, with ESM modules, we can't do this:

import { warn, error } from 'winston';

and instead have to do this:

import winston from 'winston';
const { warn, error } = winston;

This is a great blog post that explains the issue: https://simonplend.com/node-js-now-supports-named-imports-from-commonjs-modules-but-what-does-that-mean/

[DABH]

@miguelcobain Thanks for your contribution. For non-ESM modules, with your changes, will we still be able to to e.g. import { warn, error } from 'winston';? Or is this going to be a breaking change in how people are support to import the library?

[miguelcobain]

This should be a non-breaking change for anyone using regular commonjs modules.
I'm a bit confused by your example. non-ESM users right now can't use import { warn, error } from 'winston'; because that's invalid syntax on non-ESM world.

You can certainly use that import syntax if you use some kind of transpilation step (e.g Babel or Typescript), but ultimately, those tools transpile to regular commonJS require calls under the hood.

I think this change should be non-breaking. Essentially, we're just making it easier for cjs-module-lexer to detect the commonJS named exports, thus improving the esm interoperability. We're just removing some indirection in this PR.

Basically, instead of doing:

const winston = exports;
winston.version = 123;

we're doing the same in a more direct and equivalent way:

exports.version = 123;

My main question is if things like Object.defineProperty(exports, 'level', { will be properly detected under ESM modules. Not sure if cjs-module-lexer is smart enough to understand that "export". But in any case, CJS users should see no difference, and ESM users would see a major ergonomic improvement.

[DABH]

Fair enough. I'm okay with trying this, and we can always update if any other users have issues.