Handle cache invalidation for @latest versions in multibundles

[Raynos]

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

[jfhbrook]

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.

[max-mapper]

its mostly a UI issue on requirebin, I just opened an issue here max-mapper/requirebin#46

I'm pretty sure browserify-cdn is working correctly

[Raynos]

closing & migrating to max-mapper/requirebin#46

[kirbysayshi]

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.

[jfhbrook]

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

I'll reopen the issue.

[max-mapper]

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