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

feat: deprecate command #1585

Closed

Conversation

laggingreflex
Copy link
Contributor

More work towards #1518

Still a work in progress.

This is turning out to be a bigger change. Thought I'd ask for opinions before continuing.

The big parts are the two main refactors: 9717c20 & ffd71e1, latter one still a work in progress (~50 failing tests ).

If those are done properly, the feature itself seems pretty simple: c715319

Should I carry on with the refactor? Or would it be considered too large a change for a small feature?

@bcoe
Copy link
Member

bcoe commented Mar 9, 2020

Should I carry on with the refactor? Or would it be considered too large a change for a small feature?

I'm wondering if we could figure out a way to add this feature without a significant overall to commands. Commands being a fairly finicky part of the codebase.

How were you picturing that you would specify a deprecated command? It feels like if we simply made this an additional property on the command itself, like the handler, or builder, it shouldn't be too hard to output a deprecation warning without a significant refactor.

@laggingreflex
Copy link
Contributor Author

My basic assumption is that this has to be done here, which is what c715319 does (but that uses the refactor).

Without the refactor the command there is an array which traces back to

The cmd there (or any other object) doesn't seem to be available there to attach a property (deprecated).

It's all arrays and params list.

I could add the deprecated as another param?

  -self.command = function command (cmd, description, isDefault, aliases) {
  +self.command = function command (cmd, description, isDefault, aliases, deprecated) {

Initially I did go this route and found a lot of tests failing this way too (hence may have required a big change too). Should I try it this way?

@bcoe
Copy link
Member

bcoe commented Mar 9, 2020

@laggingreflex I think adding it as an additional parameter would be reasonable, even though it's a bit ugly. Maybe it's good that your .command code is a bit ugly if the command is deprecated, reminds you to actually drop the function eventually.

@bcoe
Copy link
Member

bcoe commented Apr 12, 2020

@laggingreflex want to rebase, and we can see this over the finish line? I think this is a great feature.

@laggingreflex
Copy link
Contributor Author

Please checkout #1624. It makes fewer changes.

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

Successfully merging this pull request may close these issues.

None yet

2 participants