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

Add esm #1284

Closed
xiaoxiangmoe opened this issue Jun 19, 2020 · 9 comments
Closed

Add esm #1284

xiaoxiangmoe opened this issue Jun 19, 2020 · 9 comments
Labels
docs README (or other docs) could be improved

Comments

@xiaoxiangmoe
Copy link

xiaoxiangmoe commented Jun 19, 2020

https://nodejs.org/api/esm.html#esm_conditional_exports

Add support for esm.

If you think this proposal is reasonable, I'll create a PR for this.

@shadowspawn
Copy link
Collaborator

What is the problem you want to solve? The ability to "import" Commander from code written as ES module?

While I am interested in the esm progress and how Commander might support esm, I don't think we would make it a default behaviour yet as the Node 14 version of the linked page lists this as "Stability: 1 - Experimental".

Stability: 1 - Experimental. The feature is not subject to Semantic Versioning rules. Non-backward compatible changes or removal may occur in any future release. Use of the feature is not recommended in production environments.

Related: #950

@xiaoxiangmoe
Copy link
Author

In the current situation

import { program } from 'commander';

This will report an error in mjs.

import commander from 'commander';
const {program} = commander; // Here commander and program are the same object

But this will perform well.

Should we encourage everyone to use default import in mjs?

@shadowspawn
Copy link
Collaborator

Yes, for now. The "default export" can be used in the same way as can be done with require:

// const commander = require('commander'); // cjs
import commander from 'commander';

const globalProgram = commander.program;
const myProgram = new commander.Command();

Side note 1: the exported global program is currently mainly for style, as it is the same as the default export.

Side note 2: I had actually been wondering about this style for the README for cjs, but decided the destructuring assignment was more widely used. e.g. const { program } = require...

@shadowspawn
Copy link
Collaborator

I noticed instructions for esm and cjs here, I'll keep an eye out for more: https://github.com/uuidjs/uuid

@shadowspawn shadowspawn added the docs README (or other docs) could be improved label Jul 4, 2020
@shadowspawn
Copy link
Collaborator

Opened PR to add to README: #1298

@shadowspawn shadowspawn added the pending release Merged into a branch for a future release, but not released yet label Jul 8, 2020
@shadowspawn
Copy link
Collaborator

README update released with Commander v6.0.0 : https://github.com/tj/commander.js/releases/tag/v6.0.0

I am interested in supporting esm more directly in future, when the support is stable.

@shadowspawn shadowspawn removed the pending release Merged into a branch for a future release, but not released yet label Jul 19, 2020
@shadowspawn
Copy link
Collaborator

I came across a related PR and comments about the conditional pattern: tapjs/tapjs#668 (comment)

@shadowspawn
Copy link
Collaborator

I was reading about esm again today and getting keen on adding a wrapper, when came across this reminder that using an experimental feature can have downsides. In this case end users getting a warning that (a dependent package) using experimental feature, until the warning gets removed:
nodejs/modules#485 (comment)

@shadowspawn
Copy link
Collaborator

I have opened #1440 to add named imports for esm by using a deep import. I read up on conditional imports again and still want to wait for them to be stable before including in Commander.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs README (or other docs) could be improved
Projects
None yet
Development

No branches or pull requests

2 participants