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

Feature Request: Invalidate CDN cache after a new version of a package is published #7845

Open
Jordan-Nelson opened this issue Jul 2, 2024 · 0 comments

Comments

@Jordan-Nelson
Copy link

This is a follow up to #7717 since I am not sure that the comments on that closed issue are getting looked at.

Request

Add a way to ignore/invalidate the CDN cache when publishing package to pub.

What problem does this solve?

Take the example where the following three packages are published to pub:

package_a: v1.4.3
package_b: v3.5.4
package_c: v4.5.2

package_a and package_b depend on package_c.

If I am adding a new API to package_c I will bump the version to 4.6.0 (minor release). If I want to use that new API in package_a I will need to update the constraint to a min of 4.6.0 as the API will not exist in prior versions. When I publish I will first publish package_c and then package_a. The issue is that I will need to wait for the CDN cache to expire before publishing package_a as pub will give me an error the following error when trying to publish package_a.

Because package_a depends on package_c ^4.6.0 which doesn't match any versions, version solving failed.

Current workarounds

Below are the current workarounds. Neither of these are great.

  • Ignore validation checks when publishing
  • Wait 2 minutes (possibly longer in the future) before publishing the next package

Solution

Either the cache should be invalidated when a new version is published or there should be a way to invalidate/ignore the cache when running the pre-publish checks.

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

No branches or pull requests

2 participants