Handling updates rather than running prepare all the time

When running curl -s https://gitlab.lakedrops.com/composer/plugin/drupal-spoons/-/raw/master/bin/prepareLocally.sh | bash several times, this shouldn't break anything but it takes far too long as a couple of unnecessary tasks get executed.

There are individual commands available and we should document, which ones to execute when and why.

@weitzman most of the time, the prepareLocally.sh needs to be executed once and all is fine for the lifetime of the project. Updates are only required in these scenarios:

• if the project's composer.json changes: run vendor/bin/spoon drupalspoons:prepare
• if the project adds or removes files or directories in its root: run vendor/bin/spoon drupalspoons:configure
• if new or updated dependencies are available: run vendor/bin/spoon update

So, there is no scenario where the whole stack needs to execute, just explicit what's required. Feels like this is reasonable and proper documentation should solve the issue. What's you take?

assigned to @weitzman

That makes sense for prepareLocally (IMO this should be renamed to setup).

However our plugin would take action on every composer update. This would be a good time to redo the symlinks and update composer.spoons.json for any new dependencies. We could skip the spoon update and make that an explicit action. Just thinking aloud.

mentioned in commit 14c8c6fe

Renamed the prepareLocally.sh to setup.

The other part is more difficult: when the maintainer runs composer update, the regular composer.json will be used and by design, that composer files knows nothing about spoons. That's why none of the spoons components can hook into that process. In fact, running that will remove all components that previously got installed by spoons and the maintainer would have to start over with setup.

When running spoon update we could hook into that to update symlinks, yes. But we can't effectively update the composer.spoons.json file because those changes would affect the current update process. Or in other words, we could do that but with no effect unless the maintainer runs that process twice. But that would be counter productive.

Oh right. I was forgetting that we dont ask maintainers to add our plugin to their composer.json. I would like that approach, but your proposal is easier to onboard new projects.

• if the project's composer.json changes: run vendor/bin/spoon drupalspoons:prepare
• if the project adds or removes files or directories in its root: run vendor/bin/spoon drupalspoons:configure
• if new or updated dependencies are available: run vendor/bin/spoon update

Lets add this to a README here.

I've added this to the README as well as to the info output at the end of the setup script.

closed