feat: make the cache to respect an artifact url

[alexeykuzmin]

The cache right now ignores multiple mirrors used simultaneously on the same machine.
I can lead to some non-obvious build issues.

This changes the cache files structure to the following:

/
  httpsgithub.comelectronelectronreleasesdownloadv5.0.9chromedriver-v5.0.9-darwin-x64.zip /
    chromedriver-v5.0.9-darwin-x64.zip
  httpsmyawesomemirror.comelectronv5.0.9chromedriver-v5.0.9-darwin-x64.zip /
    chromedriver-v5.0.9-darwin-x64.zip  // from a mirror
  httpsgithub.comelectronelectronreleasesdownloadv5.0.9electron.d.ts /
    electron.d.ts
  httpsgithub.comelectronelectronreleasesdownloadv6.0.2electron.d.ts /
    electron.d.ts  // a different version

[malept]

Is this a breaking change?

[MarshallOfSound]

Is this a breaking change?

Came here to comment this, I've got two suggestions here.

1. If the URL is the default URL (i.e. not a mirror) we shouldn't use a url_hash folder, it should just be top level, that way we can avoid a breaking change in the cache path.
2. Can we use something more identifiable than the cache_path like a path safe version of the mirror URL.

E.g. if the mirror url is https://mysite.com/myprefix/download/electron.zip I want the cache path to be this

/http_mysite_com_myprefix_download/electron.zip

[alexeykuzmin]

1. It doesn't look like a breaking change to me.
   A cache miss, even if a file has been previously downloaded and saved in in the cache, is a normal thing. The file could have been removed by OS or manually by a user, and it's ok to redownload it.

2. I wanted to have a reliable way to make sure there won't be any false positive cache hits.
   Are you aware of any standard ways to convert a URL to a safe file path? The one that would respect various schemes, basic credentials, and maybe even a search query parameters.

[malept]

A cache miss, even if a file has been previously downloaded and saved in in the cache, is a normal thing. The file could have been removed by OS or manually by a user, and it's ok to redownload it.

But then you have a bunch of largish dead files just hanging around for a user, if they've been working with Electron for a while.

[alexeykuzmin]

But then you have a bunch of largish dead files just hanging around for a user, if they've been working with Electron for a while.

Files will pile up anyway once you start working with newer releases.

Removing stale files from a cache might be an issue, but I think it's out of scope of this change.

[malept]

I would prefer that @MarshallOfSound's suggestion 1 be implemented.

Are you aware of any standard ways to convert a URL to a safe file path? The one that would respect various schemes, basic credentials, and maybe even a search query parameters.

Electron Packager uses sanitize-filename

[alexeykuzmin]

@malept , @MarshallOfSound another review?

[MarshallOfSound]

This is deliberate, all other artifacts have the version name in them. If this artifact does not it will be duplicated and overwritten right?

[alexeykuzmin]

It can be only overwritten if the downloader called with force: true.
electron.d.ts files for other Electron versions/mirrors will be downloaded to other folders.

The goal of this PR is to make sure every downloaded file is saved to the cache with a unique path. A folder name serves as a unique name, and a file names does not matter for caching.

[electron-bot]

🎉 This PR is included in version 1.5.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[malept]

Hmmm. I was doing some work on Electron Packager and saw that @electron/get was doing this:

@electron/get:cache Moving $TMPDIR/electron-v6.0.0-darwin-x64.zip to $CACHE)DIR/httpsgithub.comelectronelectronreleasesdownloadv6.0.0electron-v6.0.0-darwin-x64.zip/electron-v6.0.0-darwin-x64.zip +479ms

Doesn't that effectively create one folder per file? Wouldn't it make more sense to do folders like

$CACHE_DIR/httpsgithub.comelectronelectronreleasesdownloadv6.0.0

It just feels like a lot of folders to me... it's effectively doubling the number of nodes on the FS.