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

Better support for kebab-case targets #311

Open
moorereason opened this issue Jul 17, 2020 · 7 comments · May be fixed by #441
Open

Better support for kebab-case targets #311

moorereason opened this issue Jul 17, 2020 · 7 comments · May be fixed by #441

Comments

@moorereason
Copy link

I haven't seen this discussed before, so I wanted to open a discussion.

In my experience, most Makefiles that are not just cramming words together (e.g. installhtml, installps) use kebab-cased targets (e.g. install-html, install-ps) instead of camelCased targets (e.g. installHtml, installPs). It would be helpful in migrating existing Makefiles and teams to mage if mage could more easily accommodate this pattern.

I'm aware that aliases can help here, but mage Help output only shows the primary targets after running them through the lowerFirst template func.

Two ideas:

  1. Add an option to show an alias (if one exists) instead of the primary, lowerFirst target in the Help output. The user could just setup kebab-cased aliases for multi-word targets and the Help output would play along.
  2. Add an option to use kebab-casing by default instead of lowerFirst. This would avoid the need for manual aliases from option 1.
@natefinch
Copy link
Member

I like option 2 - give an option for kebab-cased targets. I think I would make this something you'd set in the magefile itself, like

const UseKebabTargets = true

that way it's standardized for everyone that uses that particular magefile, rather then being an environment variable, which would change behavior for each person (potentially screwing up other scripts and making each person have incompatible commands).

@moorereason
Copy link
Author

I was favoring option 2 as well.

@beoran
Copy link

beoran commented Mar 16, 2021

Woul n't it be easier to allow the currently implemented namespaced targets to be called using a - as well as using a : ? Then this problem would be solved more elegantly.

@jespino
Copy link

jespino commented Aug 5, 2022

I going to give it a try.

@jcchavezs
Copy link

jcchavezs commented Sep 5, 2022

Quick question: can't we support alias by default? like if we pass my-target it first tries to run myTarget and if not it fails? You can't declare func my-target() error {...} in go so it makes sense, frictionless and retrocompatible to introduce aliasing? I can come up with a PR cc @anuraaga

@anuraaga
Copy link
Contributor

anuraaga commented Sep 5, 2022

I like @jcchavezs's idea of falling back to to non-kebab if it was passed in as it seems like it'd generally help without hurting.

Another idea is to recognize //export comment on the function, this is the standard Go idiom for naming a function for use in an external system, often a C or WebAssembly library but magefile handling it would be quite natural too I think.

@jcchavezs
Copy link

I came up with a PR for this #441

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