Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

craft provider command inconsistency

See original GitHub issue

Is your feature request related to a problem? Please describe.

craft command X
# Generate class XCommand

craft provider X
# Generate class X

What do we currently have to do now?

craft provider X
# Generate class XProvider

Maybe this ain’t an issue.

Issue Analytics

State:
Created 4 years ago
Comments:9 (9 by maintainers)

Top GitHub Comments

1reaction

josephmancusocommented, Feb 6, 2020

yes the point of the Provider/Command at the end of the file is 2 fold.

it makes it easier when you import the class, what the heck it even is.
it makes searching for the file easier because you might not know the name of the listener, job, provider but you can fuzzy search it when in development. Especially when the filename is the same

2.b) I am used to naming classes like that lol

Was choosing postfix (and suffix) for Provider intentional ?

yes the BaseScaffoldCommand was created much after all the other commands were created and they were then all refactored to use this base command. Its possible that the postfix was just skipped.

For consistency, let’s just make everything use the postfix but if the postfix is in the name already, don’t add it again

1reaction

lazygurucommented, Feb 6, 2020

Exactly