CLI for scaffolding a new module

<%- if @topic_view.topic.tags.present? %>
<%= t 'js.tagging.tags' %>: <%- @topic_view.topic.tags.each do |t| %> <%= t %> <%- end %>
<% end %>

There is an official module template Github repository with a step-by-step guide about how to adjust the template when creating a new module based on it (“Steps to prepare this module for your own use”).

It still would come in handy to have a CLI tool that does all the scaffolding for you though. Since I am working a lot with Vue and Ionic, their CLIs for creating new projects come to mind and could be good role models.

After a quick web research and some Slack conversations, it appears that this was not built for Silverstripe so far.

At the moment I consider the following approaches:

  1. A clean CLI script installable via npm that serves only for this purpose
  2. A php-based solution that can be used in modules like ssconsole and sakemore

I was thinking of not only having a scaffold command but also something like “analyze” for existing modules with recommendations for changes to comply with the guideline and maybe even a module score prediction.

Before kicking this off I was wondering if anybody else has some thoughts about this?

2 Likes

Thanks for starting this discussion Julian! :slight_smile:

It might be worth clarifying what the focus of this work should be. I’m getting in the habit of forming a hypothesis these days, here’s a few that might be useful to set the scene.

  1. Newcomers to Silverstripe are more likely to succeed and stick around if they are guided through starting a Silverstripe project with CLI tools (e.g. use-case dependant starter kits)
  2. Newcomers to Silverstripe are more likely to succeed with CLI-assisted creation of Silverstripe classes
  3. Devs with some Silverstripe experience require CLI tooling rather than just documentation to make their code reuseable and create best practice modules
  4. Devs prefer CLI-assisted creation of new Silverstripe classes (even though they could write them by hand) because of productivity gains

It sounds like you’re focusing on hypothesis 3 here, right? In terms of integration, I think the more tooling we can provide through a single entry point, the more likely it’s going to be successful. sake is extensible, but also a bit of a dead end in terms of CLI experience (based on fake HTTP requests and controllers). There’s an old RFC to switch it to Symfony Console which we could revive (as a parallel tool to retain backwards compat in 4.x).

If we made ssconsole extensible, it would provide a foundation for things like ssconsole module:create. And we can add other tools like ssconsole model:create or ssconsole test:create. Here’s how laravel create works, you could adapt that for module creation. There’s a lot of good tooling for “templated” file structures in the NPM ecosystem, but it feels a bit weird to use it for a PHP-centric ecosystem? Not a blocker though, virtually every Silverstripe dev will already have NPM installed, and knows enough JavaScript to contribute.

Thanks Ingo. Yeah, although focus is on hypothesis 3 I think the first one is also relevant.

I think the following aspects are key to achieve something sustainable:

  1. Extensibility: Devs should have an option to (easily) add their own commands. Clear API and good docs required. We have a basic support for this in our version of sakemore.
  2. Usability: I like the clean approach of Laravel’s Artisan. It’s based on PsySH which is also being used in Philipp’s ssshell and our version of sakemore.
  3. Support: We already have a couple of “competing” Silverstripe tools in that area. When I was asking people about this topic one of the top requirements was to have a “one-stop shop” for all those utilities. While this makes a lot of sense it’s not that easy to achieve this. I think a statement from Silverstripe (or even a part-maintainership) would be required to get a sufficient level of trust.

There’s a lot of good tooling for “templated” file structures in the NPM ecosystem, but it feels a bit weird to use it for a PHP-centric ecosystem?

While I have some experience in building node/npm based CLIs, you are making a point here. I’ll take a PHP based CLI in consideration from now on.

When it comes to command format I very much like the following format: cli-name entity:action (e.g. ssconsole module:create).

The RFC also has some good ideas included. Too bad it’s kinda idle since 1,5 years now. Depending on how this thread turns out, reviving it would be great for this endeavour.

While I do my modules with a lot of manual copy/paste and some tools in my favourite IDE it might be good to kick it off with a CLI command, that also works in a Windows environment.

Two thoughts on it: if it’s easier to kick off a new project or module, or even for a guided setup (e.g. for silvershop) go for it! Everything that makes Silverstripe easier for new developers is good IMHO.

Regarding extensibility: I use deployer.org a lot. It’s a php based deployment tool which is easily extensible with custom hooks that are basically registered functions.

@wmk Before we’ve switched to Gitlab CI Pipelines, we used Deployer a lot. They make a good role model on how to implement a PHP based REPL, again based on Symfony Console. Their extensibility concept with registered functions is not too bad either but follows a more functional programming oriented pattern.