Option to not redownload scaffold files on install about drupal-scaffold HOT 5 CLOSED

@greg-1-anderson, @webflo, maybe we should go with a separate drupal-scaffold.lock file that can be committed to the repo and the user is in control of. That way we do not need to rely on installed.json, composer.lock or a "magic check" for the scaffold files. We also could put content in that for further features like, "never update files automatically unless triggered manually".

from drupal-scaffold.

I think we are learning why composer by default will not update scaffold files. 😄 I am not ready to give up on this feature, though; I think we have things well under control for composer update, and just need to figure out what to do on composer install and composer create-project.

An option such as "never update unless triggered manually" would be better off placed in the "extras" section of composer.json, as this would likely be a project-wide setting. I could perhaps see the logic in allowing a per-environment override of this setting, but (a) I'm not sure I see the use case (I'm not sure that a manual override option is the best way to make scaffold updates do the right thing in CI), and (b) a ".lock" file is usually something that the user saves, but does not manually edit. I don't think we should break with convention on this point.

Perhaps the real solution here is to side-step the issue, and download the scaffold files only on composer create-project and composer update, and leave composer install out of the mix entirely. This would take care of CI nicely, and would also prompt people to commit their scaffold files as they should. If anyone is starting a new project and needs the scaffold files (and somehow did not get them with composer create-project), they can always get them with composer update, or by running the scaffold operation directly.

from drupal-scaffold.

My suggestion above is not great for folks who are used to the git clone, composer install workflow. Ideally, this would get the scaffold files if they are needed, without the user needing to know anything about special rules for the project.

So, it would be good if the scaffold files automatically download on composer install, but ideally not on the CI server, in a way that is easy for the user to explicitly control. The use case here is not entirely analogous to the function of composer.lock. I am going to suggest that we use the extra section for this.

We could introduce two new options, "update-action" and "install-action", which control the behavior on composer update and composer install, respectively.

  "extra": {
    "drupal-scaffold": {
      "update-action": true,
      "install-action": {
        "if-not-env": "CI"
      }
  }

If the value is true or false, then the scaffold files are always / never downloaded. If the value is an array, then we have a number of selections available:

if-env: Download the scaffold files if the specified environment variable is defined.
if-not-env: Download the scaffold files if the specified environment variable is not defined.
file-exists: Download the scaffold files if a file exists at the specified path.
file-missing: Download the scaffold files if there is no file at the specified path.

We could have more or fewer options here, as desired (I don't know if anything other than file-missing is really needed). We could fill in a reasonable default in drupal-composer/drupal-project, such as "file-missing": "web/sites/default/default.settings.php". This would pretty much do the right thing in most scenarios without needing the user to touch it, and would be reasonably self-documenting (and would be complimented with real documentation, of course).

I'd be happy to make a PR if this sounds like a reasonable solution.

from drupal-scaffold.

I'm not set on #19. We need the right balance of configuration options vs. simplicity. Maybe just one option identifying the scaffold file to test, defaulting to index.php?

from drupal-scaffold.

I closed #19, because that PR was essentially writing code in config .yml files, which is not ideal. Code should be in code, and config should be simple.

So, I propose the following two rules:

1. drupal-scaffold runs in only two circumstances: after composer-update, and on-demand.
2. Folks who want drupal-scaffold to run after composer-install can do it in their own post-install hook.

Number 2 will essentially be for templates such as drupal-composer; we can also include instructions in our README.

In drupal-composer, we can have script entries for drupal-scaffold and the post-install hook (existing). Then, in the post-install script (existing), we can put in a code block:

if [ ! -f web/index.php ] ; then 
  composer drupal-scaffold
fi

This will do the right thing for folks who just grab the project via composer create-project or git clone; composer install: the scaffold files will be set up on the initial run, and, if they follow instructions and commit the scaffold files to their repository (which will be the path of least resistance, since the scaffold files are not .gitignore'd), then the scaffold files will not be fetched on the CI server. I think this is the simplest / least opaque solution.

from drupal-scaffold.