Skip to content
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

Invalid lockfile after modifying composer.json with plugin #8606

Open
danepowell opened this issue Feb 13, 2020 · 6 comments
Open

Invalid lockfile after modifying composer.json with plugin #8606

danepowell opened this issue Feb 13, 2020 · 6 comments
Labels

Comments

@danepowell
Copy link
Contributor

@danepowell danepowell commented Feb 13, 2020

I maintain a Composer plugin that, in part, is responsible for cleaning up people's composer.json file. For example, one thing I want to set is { "config": {"platform": {"php": "7.3"} } }.

I've seen #8259 and followed a similar technique. The problem is it results in an invalid lockfile that's missing { "platform-overrides": { "php": "7.3"} } (which I guess corresponds to the platform config in composer.json).

I'm implementing the post-update-cmd event in order to make these updates, as you can see here (please overlook how ugly this code is, it's a WIP 😄 ): https://github.com/acquia/blt/pull/4010/files

Would it help to use some other event? How can I ensure the lock file is up to date at the end of this process?

@stof

This comment has been minimized.

Copy link
Contributor

@stof stof commented Feb 13, 2020

Altering the parts of the composer.json which impact the dependency resolution is complex, because you would have to re-run the update (maybe selected dependencies are not acceptable anymore).

And for the config, you will probably need to modify the composer config, not the root package (as the config was already loaded). That may be issue in your case.

@danepowell

This comment has been minimized.

Copy link
Contributor Author

@danepowell danepowell commented Feb 13, 2020

Thanks! I confirmed that by modifying the composer config instead of root package config I can get this to work. You can see the changes in the PR linked above.

My only concern is about which event hook to use. Through experimentation, I ended up using POST_PACKAGE_INSTALL / POST_PACKAGE_UPDATE but I'm not sure if that's ideal. The problem is that some hooks (PRE_UPDATE_CMD) seem to fire before my plugin is loaded while others (POST_UPDATE_CMD) run too late to modify config.

@Seldaek Seldaek added the Support label Feb 13, 2020
@Seldaek

This comment has been minimized.

Copy link
Member

@Seldaek Seldaek commented Feb 13, 2020

Yeah that's a typical chicken & egg case.. there is not going to be a perfect solution if you can't guarantee that your plugin is preinstalled globally for users who need it. You can also listen to both events in the plugin so the first time it runs it can at least do a half-assed job and then next composer update it will trigger at the right time?

@danepowell

This comment has been minimized.

Copy link
Contributor Author

@danepowell danepowell commented Feb 15, 2020

The problem is that I want to modify composer.json during a composer create-project call, to dynamically set some values such as the PHP constraint based on the user's environment. It's a bad UX for them to get some predefined PHP constraint that doesn't match their environment, and it would also be bad to force them to manually run composer update immediately after creating a new project just to update the lock file.

Using post_package_update works for modifying composer.json and injecting the config into the update process so that it gets written to composer.lock... the only problem now is that the lock file hash is not up to date. Looking at Factory.php, it appears that plugins are registered immediately before composer.json is hashed and the Locker class is initialized. There's no hook in between those two where I could, say, modify composer.json with a plugin such that it gets picked up in the lock file hash.

To resolve this, I think we'd either need a post-plugin-activate hook (which could be pretty useful), or we need a way to force the hash to be recalculated. Does such a method exist?

@stof

This comment has been minimized.

Copy link
Contributor

@stof stof commented Feb 20, 2020

well, the thing is, we don't want to let plugins modify the composer.json between the time the solver runs and the time the hash is generated. The whole point of that hash is to check whether the composer.lock contains dependencies which correspond to the output of the solver for that composer.json. In your case, running an update with the changes applied would install different dependencies. so the lock file is indeed outdated.

@danepowell

This comment has been minimized.

Copy link
Contributor Author

@danepowell danepowell commented Feb 21, 2020

I guess this is a feature request then: as an end user, when I run composer create-project, I'd like some way to bake the minimum supported PHP version into my composer.json file, so that other people who clone my new project with newer PHP versions don't break my dependencies. Seems like a CLI parameter would be best if a plugin can't do it. Let me know if you want me to close this and open a new issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.