Just an idea (although I realize this might be a slightly bigger undertaking):
If there were some option (may that be via a config file or something else) to add custom repos that should get used, this could be a lot more useful. While I find the samples to be a great reference, they often (and I mean no disrespect by saying this) lack the setup needed for "production-ready" plugins (which is good, as they shouldn't be bloated with config files to be easy to understand, but therefore might not be as useful for real plugins).
I would suspect that users using a CLI to setup a plugin project (including myself) are the type of people who also might use CI services, Linting, Testing etc. For that, plugin boilerplates (as my own) and one's own template can serve as a far more useful starting point when creating a new plugin.
Therefore, while I do very much like the feature and its implementation, I think it would raise this from being "Oh, they've added a feature" to "Ok, that feature sound super-helpful. I'm sure I'm going to use it"...
Also, I have to admit I feel like I'd expect an interactive modal-like CLI experience to pop up when entering the command (such as the one when running
All of the above is just me adding my two cents
Apart from that, you've requested my review. As stated before, I'm in no way against the feature or its current implementation, and the above should therefore not get seen as "requests for changes" (which is also why I write this and a comment and will separately approve the changes), but just feedback regarding the feature
Hi Pablo, this is great feedback!
For both of the following, perhaps we can treat them as feature requests to build on top of the
I keep going back-and-forth on this. My original intent here was to provide a CLI feature that makes it super simple for new developers to get started.
But I can see an argument that if someone trying the Plugin APIs already has Node.js/npm installed and wants to bootstrap via the command line, that they may want more than basic boilerplate.
I'm curious to hear if anyone else has thoughts on this.
Either way, I do think we could use what's here as a starting point, and if we decide that
We could certainly add this in iteratively (as long as there's a way to bypass it, please).
Hi, sorry for jumping into the thread. This topic is very interesting for me, because of the proposed function is similar to yeoman generator for XD Plugin.
I like the idea. Also, I want to remind you that I had a similar motivation to build the yeoman generator.
I'm interested in the point, which properties do you want to customize while scaffolding?
I think the main two things would be the plugin id and name. I've stopped counting the times I've overwritten some other plugin project when starting a new project from my boilerplate, when I forget to change the id.
As most other properties have, by now, been moved from the
My intention with getting interactive there are mainly to get to a "ready for coding" stage as quickly as possible after running the command. The thing is: I have an alias setup in my terminal letting me initialize a plugin based on my boilerplate anywhere (using git clone etc.) with
When these tasks are done, I can actually begin programming, meaning if they get automated, the feature benefits my workflow as a developer (requirements here, are, of course, different, meaning an option for configuration would be great for this). Without it, this is a nice little Macro that might be interesting for new users, but won't have any benefits for more experienced users, who probably (like me) already have some sort of efficient workflow to begin new projects...
@yoshikinoko: point noted about the Yeoman generator. There is going to be room (and appetite) for bootstrappers of various kinds (Pablo has one as well that he linked to above).
Part of the goal here is to come up with a reasonable default within the CLI we already have.
Yeoman is a great option for those who already know the tool or want to learn it. At the same time, there are going to be some developers who may not want to learn/set up xdpm, Yeoman, and the Yeoman plugin. In that case, we'll have a fairly simple default right within xdpm that they can reach for.
Just pushed a change to address this.
For these, further discussion would be warranted, and PRs are welcome.
I know @pklaschka also has thoughts on stdout/stderr output and how it can be leveraged in CI/CD. I think this subject warrants a concerted discussion and CLI-wide review, which I don't think can be addressed in the scope of this particular feature branch.