Allow configuring which theme is used as a starterkit theme

💯 on board for this.

Am I right in assuming this feature request is different from https://www.drupal.org/project/drupal/issues/3206217
because this request means giving the possibility to provide your own template files (not just a starter kit in Core) and thus generate a completely custom theme? But with passing extra options/functionality, much like drupal console allowed you to do?
Would this include the possibility to hook into the generate command and extend it so you can have the generator copy extra files and folders or replace custom variables inside twig and yml files for example?

no longer fits into 9.3

I'm going to take a stab at this. If anything, to push for some more requirements.

Per #4: #3206217: Allow starterkit themes to control how the theme is generated seems to be more about the theme hooking into the generation process, so it is less static instead of the current "this is the way, and that's it."

The way I see this issue is that the info.yml has a new flag like starterkit: true and this says "k, we can scaffold from this sucker."

Once we have this, it would make it easier to test out #3206217: Allow starterkit themes to control how the theme is generated because then we could create a test starter kit theme and not rely on the current one.

Here is the initial work. I didn't add a starterkit_theme_test which could help verify this works. I wanted to keep the MR tidy until then. I used this to make a new theme from Olivero (hacked it locally to have the flag) and it worked like a charm.

Fixed CS errors.

Fixed phpcs in MR and added mystarterkit to cspell

Thanks for working on this! I found a number of issues:

I tested this by adding starterkit: true to olivero.info.yml and then running php core/scripts/drupal generate-theme --name "mike" --starterkit olivero mike

If you search the new theme (named "mike") for the olivero string, there's a lot of returns. Some of these are worse than others.

• "Olivero" namespace in mike.breakpoints.yml
• Dependencies on Olivero libraries within mike.info.yml
• Dependencies on Olivero within mike.theme
• Olivero namespace within theme-settings.php
• Olivero named files and "olivero" theme dependency within all of the config yml files within /themes/mike/config/install
• Lots of Olivero namespaced items within both the CSS and JS

IMO, the new theme should be a duplicate of Olivero but have absolutely no dependencies and not use the Olivero namespace within it. Maybe we could create a test that verifies this?

I agree we need some kind of test. I missed the things named Olivero 😬. One problem is that Olivero isn't designed for a starterkit.

We'd need to make another starterkit test theme.

The problem is: is the problem for this issue or is this now becoming meta to flush out missing features when generating a starterkit?

Yeah, my thought is that we have some Olivero namespaced JavaScript objects, etc. Should these be namespaced something more generic like "theme"? Because what if a user decides they want the machine name of the theme to be "this" or something. It'd break everything.

Should we modify Olivero (and other themes) to make them more friendly to being a starterkit? If so, what needs to be done? I'm not opposed to doing so. Giving a quick look at the CSS and JS, it'd be pretty simple to refactor it out and call it "theme" or "drupaltheme" or something.

Should we modify Olivero (and other themes) to make them more friendly to being a starterkit?

To me, that is up to the developer who created the starterkit.

Because what if a user decides they want the machine name of the theme to be "this" or something.

We can come up with "reserved" words.

---

These problems arise if we allow any theme to be a starterkit. And that's not the intent. So any of these problems are valid, but I don't think they block this issue. They are follow ups and things to address as starterkits are used more often.

I'm putting it back to Needs Review as we need input from @lauriii and others

Copying in some information from Slack: https://drupal.slack.com/archives/C1BMUQ9U6/p1640798812123800

I pinged @lauriii about scope creep with things found in Olivero.

I’m wondering if we should figure those things out in https://www.drupal.org/project/drupal/issues/3206217
I would think it would be fine as long as we don’t add starterkit: true to Olivero in this issue

#3206217: Allow starterkit themes to control how the theme is generated

We need to add tests to \Drupal\Tests\Core\Command\GenerateThemeTest

Added test case for

* Specifying a starterkit that is a non-existent theme
* Specifying a theme that is not flagged as a starterkit (explicitly false)

Adding scope to summary

Adding testing instructions to summary

This looks great! It works well, seems to be full tested (and tests pass).

I created and followed the testing instructions in the summary and this works as expected!