Create a Field Module template repo

[jgaehring]

Seems like a good idea to settle on a structure for this with the first sprint of module development. It would be good to revisit directory structure when we do this, too, since we only need to support farmOS 2.x.

[mstenta]

Yes! Reminder that I had started something a while back over here: https://github.com/mstenta/farm_client_module_template

That mainly included a GitHub Action for running npm run build and pushing a release tarball to GitHub.

Now that we've decided Field Modules will only target farmOS 2.x, we can refresh on where we left off with the template ideas. It will simplify it greatly if we don't need to include files for farmOS 1.x support as well.

[mstenta]

And I had documented some of our next step decisions in the issue queue of that project: https://github.com/mstenta/farm_client_module_template/issues

[mstenta]

I'm also curious to take a look at the drush generate command, which can be used to create boilerplate Drupal modules/plugins/services.

https://www.drush.org/commands/10.x/generate/

Do I recall you mentioning a similar option that npm provides @jgaehring ?

[mstenta]

Oh also I want to bring our attention to this discussion in the farm_eggs module (which is more general than that module): https://github.com/farmOS/farm_eggs/issues/4

TL;DR: we may find that we need to use GitHub for packaging, but also mirror repos on drupal.org so that translatable strings can be found for localize.drupal.org...

(Sorry maybe not directly relevant to this issue, but didn't want to lose track...)

[jgaehring]

Do I recall you mentioning a similar option that npm provides

Sort of? There's no standard npm script for doing it. Really what I was thinking was just creating a Node CLI tool that could be run and would scaffold the project, probably by prompting some questions then interpolating the template with things like the module name, etc. I had in mind something like create-react-app.

I think it really depends on what we're trying to generate, and how much interpolation is required. I'd prefer to use a Node tool, b/c that's what I and other JS devs will be used to, but if it's way easier with Drush, then we should probably start with that.

[mstenta]

Makes sense! I've never used Drush Generate myself - I think it provides similar potential, but I agree that JS devs are more likely to be the target audience.

Let's find a time to do another live sketch session where we mock up the required directory structure, without the D7 stuff we were including before...

A template repo is a simple first step and can provide a start to a CLI tool in the future, perhaps.

[symbioquine]

Kind of a similar concept, I've created a repository demonstrating how to embed a Vue.js app as a farmOS contrib module; https://github.com/symbioquine/farmOS_vue_page_demo

[jgaehring]

Oh nice! This could also be relevant to the idea we've discussed of using Field Kit's Vue component library in farmOS itself (farmOS/farmOS#239). I'll definitely have to revisit this and dig deeper into what you've done here.

[jgaehring]

I'm looking at options for a separate build process for #446 and came across a few options that could make it quite feasible, even easy, to write a Node CLI tool for scaffolding a Field Module project:

• Vite's build and other JavaScript API's
• Rollup's core replace plugin
• js-beautify for file formatting
• js-yaml for outputing the YAML config files for Drupal

[jgaehring]

A few more resources...

I looked up command line frameworks, and seems like there 3 popular options:

• commander
• yargs
• oclif

Commander is definitely at the top of the heap, but yargs is also pretty well established. oclif (Open CLI Framework) is the hot new thing, made by Salesforce, which seems to have a lot of fans.

I also rewatched the Fireship CLI tutorial, which had some other good libraries to recommend:

• inquirer (for CLI prompts)
• chalk
• chalk-animation
• gradient
• figlet (for ascii art)
• nanospinner

Top among those is inquirer, which I'll definitely want for getting the name and other package info for the template.

[jgaehring]

Maybe not strictly related to the template repo, but I found this Vite plugin that might be useful for bundling modules:
https://github.com/originjs/vite-plugin-federation

[jgaehring]

Another great example of a similar templating tool is create-vue. It's pretty simple as it is and since our initial requirements are pretty basic, I could probably borrow a few ideas from it to whip together a super simple script for templating field modules. It mostly uses prompts under the hood, together with Node's fs API. The real meat of it is in the utility function renderTemplate, just 42 loc.

I don't think I even need to worry about using a tool like Rollup's replace plugin, like I mentioned above, as simple string concatenation and a bit of String.prototype.replace() should be all I need.

[symbioquine]

I was just looking into this in another context the other day. Another option is described here: https://rclayton.silvrback.com/templatizing-github-template-repos

[jgaehring]

Oh, I like that, @symbioquine, nice find!

I've come to the conclusion that it's probably best to avoid using GH Template Repos entirely for this, because (as that post's author pointed out) they don't really provide a whole lot of utility other than deleting the .git directory for you. My goal here is mainly twofold: 1) zero additional* requirements (* = not counting Node and npm, b/c you can't develop and/or build a field module w/o them); and 2) enforcement of naming conventions. I'm guessing gomplate would be really sweet for that second point, but seems like it would add more complications to figure out how to bundle it with an npm package. Ultimately I want the whole thing to work with npx in just a few lines:

npx create-field-module field-module-compost # then answer some Q's via CLI
cd field-module-compost/
npm start # opens dev server at localhost:8080