Commander.js v3.0

[roman-vanesyan]

Tracking list of features and issues to be resolved before v3.0

Features

Issues

• argument 'once' (and probably others) cause naming collision #404

Tooling

• Switch testing to jest
• Test also on Windows

[shadowspawn]

@vanesyan asked elsewhere:

Should we open an issue to collect all wanted breaking changes and finally decide on v3?

Well, there is this stale old issue! Asking some questions first. Numbering them so you can reference them in replies, but also putting them in separate comments do you can just 👍 👎 too.

[shadowspawn]

1. Are there going to continue being minor releases before next major release?
   Edit: yes?

[shadowspawn]

2. I have not looked through open Pull Requests yet. Would you like me to look for stale Pull Requests, like I have with Issues, and close old ones that did not get much activity? (Open Issues count is down from 223 to 142 so far, but I expect I will not close so many Pull Requests.)

[shadowspawn]

3. We could perhaps try a Project for tracking v3?

I have experimented a little but not used a Project for real work yet, so not sure how well it might work. No worries if you would rather just use Issue!

I was thinking we might have columns for Consider, To Do, In Progress, Done (Merged).

Adding issues directly to the project and moving an issue between columns adds messages to the issue (so noisy). But you can also add Notes which can mentioned Issues, and these do not generate visible activity in the Issue so we can try it out quietly too.

Edit: perhaps not Project, just discuss issue by issue and merge them into a release branch as we go.

[shadowspawn]

Mentioning other collaborators in case not subscribed to all new messages. No rush replying, just letting you know I added some notes in this older issue! 🙂
@vanesyan @abetomo

[shadowspawn]

4. Do we have an existing policy for minimum node version?

I would like to say LTS but that is probably too aggressive for such a widely used package! I saw Vanesyan mention ECMAScript 2015 in #637 and found a site with detailed information about what version of node supports ECMAScript features: https://node.green

jest and mocha both currently have a min version of node 6, so I suggest we aim for that unless we get further information.

[shadowspawn]

5. api docs

How are the api docs on http://tj.github.io generated and updated from the jsdoc comments?

I am wondering partly from a maintenance point of view, but also because I do not know JSDoc and wondering what tools we are using so I do things correctly. (For example @api private is not listed as a standard attribute on the pages I consulted, but does appear to keep routines out of the api docs.

edit: probably generated using https://github.com/tj/dox (another tj project!)

[shadowspawn]

6. testing framework

We have suggestions for Jest and Mocha and Ava, and #649 has multiple comments. Also mentioned in #661.

I thought it was a good experiment in #755 to convert a couple of the tests to ava, and wonder about doing same for Mocha and Jest.

Would it be useful to convert same couple of files for Jest and Mocha to help decide? (Or thumbs down if you already have a strong preference or it would not help you decide!)

[shadowspawn]

7. release branch

Shall we make a release branch for pull requests which have been approved for next version, and use that branch for new Pull Request that must target next version? (I am thinking yes, and I'll also add a tag to mark Pull Requests that have been merged into the release branch but not into master so we know those Pull Requests are done and just awaiting release.)

[shadowspawn]

8. milestone to track v3.0.0?

The other good option for tracking a release is milestone!

I expect the items get ticked off as merged so I think we would change the base branch to v3.0.0 when merging the pull requests. Still thinking about this approach but current favourite...

Discussion about whether something should be in v3.0.0 can take place in the Issue/PR

[shadowspawn]

Note: original v3 WIP PR was #661 and has some commits which might be consulted or cherry picked, especially for ES6 changes.

[shadowspawn]

Update on comment 2. open Pull Requests. I have looked at every PR adding comments and closing the ones I think we should not proceed with at this time. (Please feel free to reopen or comment on any you disagree with closing so we can discuss them.)

We are down from 58 open PR to 22, including some reviewed and merged.

[shadowspawn]

I would like to be added as npm owner too at some stage please, and that does not need tj. Any current owner can do it:

npm owner add shadowspawn commander

Docs: https://docs.npmjs.com/cli/owner

[roman-vanesyan]

@shadowspawn done!

[shadowspawn]

Confirmed, thanks @vanesyan

[shadowspawn]

I have created a milestone for a less ambitious v3.0.0 which includes all of the open Pull Requests that I am happy enough with to finish myself if necessary. I'll create a release branch and start merging in code.

If I mark something for v3 that you have concerns about, please do add a comment in the Pull Request.

I'll add a comment when I start looking at a Pull Request, and raise any concerns I uncover. If you want to prepare one of the requests yourself, stick in a comment so I don't grab it.

[shadowspawn]

(And do feel free to add a comment if I am leaving out something you think should be included in v3, either in the Pull Request or in the milestone.)