BLT Schema out of date process...

[dpagini]

My system information:

• BLT version: 8.9.2

So we have a dev that pulls down the latest master branch with the BLT update as part of it, and they run a $ blt setup or some other command. BLT then prompts them that the schema is out of date, and asks if they want to run $ blt update (which all the files in master are already updated, it's just the vender version of BLT that is out of date). Instead of going to this prompt first, could an "out of date schema" detected run composer install and then check again before the prompt?

[grasmash]

This seems reasonable, but I would avoid executing composer install until after the user has answered the prompt affirmatively.

[dpagini]

What should a dev answer to that question though? I guess I was thinking the $ blt update command only needed to be run one time per project per release, but maybe it's meant for every user to run?

The problem I run into is things like comments I put into blt/project.yml (just one example) the BLT update process wipes those out, and that would happen for every dev to decide to revert that file or commit the changes. When I upgrade our project, I usually have to parse that file for changes meant for the upgrade process vs BLT wiping out comments, or other changes. Another example is I keep our toggle modules in the below format (which lets me more easily overwrite them in project.local.yml or site.yml) and BLT converts this back to a single line array.
Anyways, that's the long way to say that I have some customizations to various files that don't play nice/seamless with BLT upgrades and it's tough to put that responsibility on our whole dev team when all they really need is a composer install.

toggle-modules:
  local:
    enable:
      - devel
      - views_ui
      - etc

Edit: Is there a composer command to see if what you have installed does not match composer.lock file? That's really the scenario here.

[thom8]

You could use composer install --dry-run but the project is in a bad state if there's differences between the lock file and the currently installed pacakges.

[dpagini]

but the project is in a bad state

But I mean, this isn't "the project" it's just the developer's branch. This happens, BLT or not, everytime there is an update to composer.json. Right?

[thom8]

Any branch could have a different dependencies so it's a good idea to run composer install when ever you switch branches.

The install command is completely idempotent, as long as you have a lock file so it's doesn't matter if it's run without making any changes.

[grasmash]

Any branch could have a different dependencies so it's a good idea to run composer install when ever you switch branches.

This is also my thinking.

I wonder if we should consider introducing new git hooks that would execute composer install after switching branches or pulling down new code? There is a post-checkout hook.

[dpagini]

Oh that's a cool idea...!
I think in the time being it seems more like a dev training thing to just make sure people run composer install more often. It's tough b/c at a point in a mature project there are so few composer updates done, so more often than not it's not needed.

[grasmash]

it seems more like a dev training thing to just make sure people run composer install more often.

I think that this is the best solution. Please feel free to open another issue if you would like to make a feature request for the referenced git hooks.

[thom8]

I prefer to using custom composer scripts so we have build, test & deploy

    "scripts": {
        "build": [
            "@composer install -n --ansi --prefer-dist",
            "blt sync:refresh --ansi"
        ],

Then whenever you checkout a new branch you build it -- composer build.

Before creating a new PR you can test it with composer build && composer test.

The added benefit here is that you don't need the blt aliases configured as script automatically puts the project bin into the PATH, so composer is the only requirement for building the project.