[Refactor] swap cacache with another cache

[filipesilva]

Heya, would you be receptive to swaping the cacache dependency with another cache library? I can do the PR with the work for it.

I ask because I was trying to update uglifyjs-webpack-plugin to the latest beta in @angular/cli, and a couple of new licenses came up.

Both cacache@9.2.9 and ssri@4.1.6 (a dependency of cacache) use the CC0-1.0 license (https://spdx.org/licenses/CC0-1.0.html). This license is problematic to use in Angular because it does not allow transfer of copyright and does not address some required formalities.

[TheLarkInn]

This would leave me to believe this is likely incompatible with JSF license also.

[alexander-akait]

@filipesilva sounds reasonably, but first we should merge #108, because this PR done breaking changes (separate cache and parallel), also repair logic around cache (now cache and parallel is broken and can output invalid data from cache, also parallel works incorrect too).

[filipesilva]

@evilebottnawi SGTM, I put a #121 but marked it as WIP and blocked by #108.

[joshwiens]

@TheLarkInn - Replace likely with is. I'll get it on the working list to add license checking of dependencies as a part of our validations.

[mikesherov]

May I suggest using license-to-fail for license checking?

[alexander-akait]

@mikesherov please create issue about this in webpack-defaults (https://github.com/webpack-contrib/webpack-defaults)

[michael-ciniawsky]

cacache (#109) && ssri (#8)

[michael-ciniawsky]

🤞

[joshwiens]

cacache is still overkill & quite frankly, the issue driving all of this ( performance refactoring ) is blocking the 1.5 release of the angular/cli.

We have a tool that is capable & can get the job done now, unless flat-cache comes with an unacceptable performance hit or is lacking in features (we don't use anyway) this is moving forward as discussed in #121

[TheLarkInn]

Yes let's do this

[zkat]

tbh I've been meaning to relicense both of these, so that might happen soon. If you feel like it's overkill, that's sensible. I'd love to hear why you think it's a bit much for this use case, out of curiosity (and I'm not at all challenging the idea here! cacache does a bit!)

[joshwiens]

@zkat - It's honestly more about trying to avoid hangups with lawyers ( shiver ) & not blocking a release for the angular group in the mean time.

I'm always down with sticking with what works & cacache is already proven to get the job done. And for reference, cacache is far from overkill, i use it professionally & love it. This plugin doesn't leverage a lot of it's bells & whistles so perhaps underutilized would be a better word.

So ... if you are down to swap that out with something we & the Angular group can consume ( I don't know their licensing constraints //cc @filipesilva ) && they don't mind waiting X number of days for the change and what I am sure will require a quick email to legal folks to verify every thing is cool then it's should be a simple as changing the minimum version and calling it a day.

[filipesilva]

@zkat did you have a specific license in mind? MIT works for us but it's not the only one.
/cc @hansl

[michael-ciniawsky]

@filipesilva I just suggested MIT out of the blue in the meantime :), since there shouldn't be any issues with that licenses at all. But ISC is prefer by @zkat and npm related projects in general as it seems and if that works with the JSF && Google policies. Otherwise can we try to find consensus/agree upon just simply going with MIT 🙃 ? Would be highly appreciated🙏

[hansl]

ISC, Apache v2 and BSD are also acceptable by most lawyers (if not all). The problem might be timing since we need this done over the weekend.

[zkat]

The license would be either ISC or MIT. We tend to prefer ISC mostly 'cause that's the one we use, but that shouldn't make much of a difference, I don't think.

I've already pinged our own legal folks about it -- the CC0 "license" is largely my fault for being kind of "quirky" about licensing before, but it seems to cause more trouble than it's worth. ssri should be pretty quick to switch over, since it's only npm employees who used it, and cacache should take a bit longer 'cause I need to seek approval from a few outside contributors, but it should still be tenable (once I get the 👍 from our folks to start, I imagine it wouldn't take more than like a week or so).

As far as underutilized? I think you probably use more of it than you think! Considering that the main API is really just put and get -- a lot of the magic is in the cache verification and concurrency (did you know that you can hit cacache in parallel without needing any sort of lock?)

[zkat]

There are now PRs which should be landing soon relicensing both projects:

• cacache: feat(license): relicense to ISC zkat/cacache#111
• ssri: feat(license): relicense to ISC zkat/ssri#9