Composer files not updated when new version fetched

[rayrutjes]

There is a discrepancy when a user manually asks to update a given repository.
The display will show the latest version, but this version will not be available for use in composer until the build command is ran.

[khromov]

Hi @rayrutjes and thank you for your bug report.

Please provide:

• Exact reproduction steps (ie. which commands you are running, along with your composer.json / composer.lock files)
• Your result
• Your expected result
• Composer / PHP version

[rayrutjes]

Thanks for the quick reply @khromov .

Reproduction steps:

• Go to the frontend interface
• Click on the "refresh" icon of a plugin that has a new version that has not been refreshed yet
• The version is correctly added to the list
• But the composer file does not include this new version and as a result, you can not yet fetch this new version from your project

As a user I would expect that the UI reflects the state of the composer repository.
If a version is displayed, then it should also be available from composer.

I guess this is a tricky one since there isn't such thing as updating a single composer entry for a given plugin. This is only updated at each cron run of php bin/cmd build.

[khromov]

Thanks for those additional details, I understand the issue now.

Rebuilding takes about 15 seconds on my computer, so it's not prohibitively expensive to do it on an update. However, it might exacerbate a problem that I've noticed where if the build script runs while you are performing a composer update, the file names that hold plugin data will have brand new hashes and so you'll get 404 errors midway through your command.

@joaquimds Maybe you have some input regarding this?

[ethanclevenger91]

Just ran into this myself. Would love to see an update! For posterity's sake, how often is the wpackagist composer repository rebuilt?

[NoelLH]

@ethanclevenger91 this is an open question! #350 and underlying bug #368 are outstanding and should unlock testing of much faster updates.

I think the refactoring & fixes already written will also address the immediate rebuild step, hopefully also mitigating the risk of resulting 404s. But we can re-test once we have resolved the bug blocking deploying the changes.

[NoelLH]

The logic changes which do all the steps for a specific package on-demand are now live. I'll close this for now – please reopen if you find the problem's ongoing.