wzrd.in icon indicating copy to clipboard operation
wzrd.in copied to clipboard
verified publisher icon browserify

Handle cache invalidation for @latest versions in multibundles

Open Raynos opened this issue 11 years ago • 6 comments

When i do console.log(require('mercury').h) in requirebin, it prints an old version of h

It looks like this is a cache invalidation problem or an issue of getting the wrong mercury.

Maybe this is a problem in wzrd.in

Maybe this is an issue with requirebin accepting any version of mercury.

It would be nice to:

  • always get latest
  • see which version i get in requirebin
  • have a cache bust opt in

This is also a requirebin UI issue.

Placing this issue here since I think the root cause is cache invalidation.

cc @maxogden @jesusabdullah

Raynos avatar Apr 18 '14 22:04 Raynos

Here are things I know:

  1. {module}@latest tries to resolve the latest version of the module. https://github.com/jesusabdullah/browserify-cdn/blob/master/bundler/registry.js#L53-L55
  2. Caching should get busted when new versions are published. https://github.com/jesusabdullah/browserify-cdn/blob/master/bundler/npm-cull.js

It's possible there's a bug in here somewhere.

jfhbrook avatar Apr 18 '14 23:04 jfhbrook

its mostly a UI issue on requirebin, I just opened an issue here https://github.com/maxogden/requirebin/issues/46

I'm pretty sure browserify-cdn is working correctly

max-mapper avatar Apr 18 '14 23:04 max-mapper

closing & migrating to maxogden/requirebin#46

Raynos avatar Apr 19 '14 00:04 Raynos

Sure, the cache is busted for individual packages, but what about for multi bundles, which I believe is what requirebin is using? Seems like those are cached based on hashing the POST payload (https://github.com/jesusabdullah/browserify-cdn/blob/a64785faaf0325093a0552f9206c8384c017c6c1/multiple.js#L52). This means the cache wouldn't get invalidated by a package update to npm if someone was using @latest on wzrd.in, since there isn't a way for browserify-cdn to know what multi bundles a package is a member of.

Unless I'm misunderstanding?

For reference, I published a package a half hour ago, and while the /bundle @latest route for the package began returning the newest version after about 10 minutes, a previously requested /multi containing that package is still sending back the previous version.

kirbysayshi avatar Apr 20 '14 07:04 kirbysayshi

No, I think you're correct. Of course, fixing this is non-trivial.

I'll reopen the issue.

jfhbrook avatar Apr 20 '14 14:04 jfhbrook

ah, right, we need to:

  • index multibundles by all individual modules within them
  • invalidate an entire multibundle if any of the individual modules get updated

max-mapper avatar Apr 20 '14 19:04 max-mapper