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

version command #11

Closed
rishson opened this issue Aug 11, 2016 · 6 comments
Closed

version command #11

rishson opened this issue Aug 11, 2016 · 6 comments
Assignees
Milestone

Comments

@rishson
Copy link
Contributor

rishson commented Aug 11, 2016

This should output the versions of all registered groups, e.g.

dojo version

The currently installed groups are:

build (dojo/cli-build-webpack) 0.23.121
build (someAuthor/dojo-cli-MyBuildCommand) 1.2.3
test (dojo/cli-test) 0.3.22
...

You are currently running dojo-cli 2.1.223

Users can then copy and paste this info into issues raised on GH. This allows a user to provide version information as easily as possible, thus increasing the likelihood that they will include this information in GH issues.

@rishson
Copy link
Contributor Author

rishson commented Sep 30, 2016

Are we assuming that every command will be distributed via npm?
If so, then we can enhance the cli to parse each command's package.json for the version.
Otherwise, we should add version to the command interface and each command should return its version that can be called by the cli.

My initial thought, is we do the former for now and later we could always implement the latter, which we could use if no package.json is found.

Thoughts?

@agubler
Copy link
Member

agubler commented Sep 30, 2016

It's a good question, perhaps have version first look up a package.json and then fallback to calling a version API? Or perhaps the other way round, it it's implemented use the version function otherwise try using package.json otherwise show output unable to determine command version

@rishson
Copy link
Contributor Author

rishson commented Sep 30, 2016

If I was a command author, then I'd want to do the least amount of work as possible.
version first allows the command author to override the default package.json behaviour and is therefore more flexible, but allows them to do the least amount of work, e.g. if on npm then it already has a published version. Therefore I think version then package.json then can't find version is the least effort for the command author, and the most flexible.

@agubler
Copy link
Member

agubler commented Sep 30, 2016

basically I agree, I was pretty much typing as I was thinking so certainly the implementation of version would want to override the default behaviour of looking in the command's package.json

@rishson rishson modified the milestones: 2016.10, 2016.09 Oct 3, 2016
@rishson
Copy link
Contributor Author

rishson commented Oct 3, 2016

As noted in the first comment, we should never have the situation where a group has multiple commands with the same name if we only support npm right?

@agubler
Copy link
Member

agubler commented Oct 11, 2016

This is a core CLI command, that will determine the version of all available commands and print them out.

After some offline debate, it was decided to only support versions for commands that have a package.json (therefore use the version from the package.json)

@rorticus rorticus self-assigned this Oct 11, 2016
rorticus added a commit to rorticus/cli that referenced this issue Oct 12, 2016
rorticus added a commit to rorticus/cli that referenced this issue Oct 12, 2016
rorticus added a commit to rorticus/cli that referenced this issue Oct 12, 2016
rorticus added a commit to rorticus/cli that referenced this issue Oct 13, 2016
rorticus added a commit to rorticus/cli that referenced this issue Oct 17, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants