-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Check installed.json #7
Conversation
I do not get your changes. What do you want to achieve with it? |
It is the result of a lengthy in IRC with @greg-1-anderson. I was trying to prevent the update of the scaffold in CI environments. I think we want to keep the committed scaffold file in any case, even if we install a new version of the package. Because a developer did the update before and committed the files already. |
The proposed solution is not correct, i still try to locate the proper information in the composer event. |
I think #7 (comment) is on the right track. Since we are not trying to detect exact version changes in |
… update into separate post-event handlers.
I just added a commit to #6 to refactor this per my comment above. Next I'll add a check to see if any (all?) of the 'include' files already exist, and, if so, prevent install from updating the scaffold files. Then I think we're pretty much there, save for the remaining limitation that we can't perfectly restore the scaffolding files to the same state after a In IRC, @webflo and I seemed to think this limitation was acceptable for now, since it is advisable for folks to commit the scaffolding files to their repository anyway. |
I think #6 now satisfies our use-cases vis-a-vis |
@greg-1-anderson @derhasi Thought about it again, and we should check the composer.lock instead of installed.json. Checks against |
We should go with #8 |
No description provided.