Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use ESModules instead of module.exports #786

Open
jehon opened this issue Oct 6, 2020 · 22 comments
Open

Use ESModules instead of module.exports #786

jehon opened this issue Oct 6, 2020 · 22 comments

Comments

@jehon
Copy link

jehon commented Oct 6, 2020

Today, debug use module.exports facility.
But nodejs and browser can support import / export notation, aka es6 modules.
While preparing the v5, why not going into that mode?
#656 ?

@Qix-
Copy link
Member

Qix- commented Oct 6, 2020

It's not supported natively, so a build step would be required. Unfortunately, package management for the different types of modules still is pretty terrible. This is why most large modules are still CJS exported.

@jehon
Copy link
Author

jehon commented Nov 3, 2020

You are right...

Conditional exports be a solution when not experimental anymore, or for next major:

// package.json
{
"main": "./main-require.cjs",
"exports": {
"import": "./main-module.js",
"require": "./main-require.cjs"
},
"type": "module"
}

https://nodejs.org/dist/latest-v15.x/docs/api/packages.html#packages_conditional_exports

Storing it here to not loosing this...

@tverilytt
Copy link

Any news on this topic?

@tverilytt
Copy link

In Node.js ESM this works for me:

import debugModule from 'debug';
const debug = new debugModule('foo');

@Qix-
Copy link
Member

Qix- commented May 21, 2021

Yep, v5 will be pure ESM.

@jimmywarting
Copy link

It would be cool to see debug being a ESM only package, It would put pressure on many packages towards upgrading their commonjs packages to ESM as well and benefit the hole js ecosystem in the end.
otherwise they can still use a older version of debug

@mrmckeb
Copy link

mrmckeb commented Aug 25, 2021

Hi @Qix-, we've been working on ESM support for ms, and it would be great to get your feedback if you have some time:
vercel/ms#163

This work is also published as 3.0.0-beta.2.

@milahu

This comment has been minimized.

@Qix-

This comment has been minimized.

@milahu

This comment has been minimized.

@Qix-

This comment has been minimized.

milahu pushed a commit to milahu/debug-esm that referenced this issue Nov 27, 2021
@debug-js debug-js deleted a comment from milahu Nov 27, 2021
@lubomir-haralampiev
Copy link

lubomir-haralampiev commented Jan 6, 2022

The workaround suggested in the comment above

In Node.js ESM this works for me:

import debugModule from 'debug';
const debug = new debugModule('foo');

didn't work for me with the version 4.3.3.

I get the error TypeError: debugModule is not a constructor.

Generally if I have "type": "module" in my package.json an import results in an empty object {}. Importing it in a cjs module results in a function.

Any other workaround for usage in an es module? Or do I better wait for the next major release?

@Qix-
Copy link
Member

Qix- commented Mar 4, 2022

import makeDebug from 'debug';
const debug = makeDebug('foo:bar');
debug.enabled = true;
debug('hi');

Works fine for me.

@jimmywarting
Copy link

we should at least discourage this antipattern var debug = require('debug')('http')

it's bad to call/chain require, it only makes it harder for those who wish to swtich to esm at some point later
should rather be

const debugFactory = require('debug')
const debug = debugFactory('foo:bar')

@Qix-
Copy link
Member

Qix- commented Mar 4, 2022

@jimmywarting agreed, PR welcome. That's a good start.

@Qix-
Copy link
Member

Qix- commented Mar 8, 2022

Debug is not a class. Don't call it with new.

@jmcombs
Copy link

jmcombs commented Mar 8, 2022

Debug is not a class. Don't call it with new.

Thank you, @qix. I deleted my comment since it was incorrect.

@dmnsgn

This comment was marked as off-topic.

@Qix-

This comment was marked as off-topic.

@webketje
Copy link

webketje commented Jun 3, 2022

I've been doing similar research into CJS/ESM for metalsmith and documented findings in this issue. TLDR:

Tests using a linked metalsmith package on diffferent Node versions with NVM resulted in inconvenient results for either the user (both ESM/CJS) or the maintainer:

  • specifying a package.json exports property will almost certainly result in a semver-major breaking change
  • specifying a shallow index.mjs wrapper and declaring"type": "commonjs" was inconvenient for ESM users as you needed to import from '/index.mjs'
  • declaring "type": "module" would require including a bundler with dual ESM/CJS builds
  • unit testing (with mocha) was a pain

In the case of debug, potentially even more build outputs would be required to work with native browser imports & bundlers.
The only "safe" option to support both CJS/ESM with no rewrite required in Node was using a single module.exports = default export as debug does in v4

@mariusrak
Copy link

Not using ESModules is breaking my build. This lib is buried deep in dependency chain of a lib I wanted to use and it is now not usable beucause of the incorrect modules.export usage. So, please fix soon, as this might break down many builds.

@amritk
Copy link

amritk commented Apr 12, 2024

import makeDebug from 'debug';
const debug = makeDebug('foo:bar');
debug.enabled = true;
debug('hi');

Works fine for me.

hey @Qix-
How do you get this to work? I get the following error: x does not provide an export named 'default'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.