Correctly Report `zip:` URI with no matching open zip

[justarandomgeek]

trafficstars

I'm trying to integrate with this extension from my Factorio Mod Debugger to allow stepping through files in zipped mods.

So far I've got it to work if I manually open a file within the zip first (so, i'm clearly translating paths correctly), and I've automatically registered all the zips as I start a debug session by calling "zipexplorer.exploreZipFile" on them, but any action that causes VSCode to automatically open a file (like hitting a breakpoint in a not-yet-open file) within one of the zip url trees just leaves me with a blank editor with a "wait" bar cycling around the top forever.

[justarandomgeek]

This is at least partially caused by getContent never resolving or rejecting its promise if it does not find a match. I'm having trouble figuring out what I've done wrong to the URI in my extension to cause it to not match up. It would be significantly easier if you split the zip: uri scheme to use path for the zip and query for the path within the zip!

[justarandomgeek]

I hacked the js in my extensions dir to this which at least reports the failure to match, but i'm confused why it does so in situations that look like they match to me

    getContent(uri) {
        return new Promise((resolve, reject) => {
            const zip = this._zipRoots.find(zip=>uri.path.startsWith(zip.sourceUri.path));
            if (zip)
            {
                const filePath = uri.path.substr(zip.sourceUri.path.length + 1);
                resolve(zip.getText(filePath));
            }
            else
            {
                //reject("No Matching Zip");
                resolve(`No Matching Zip for '${uri.path}' in \n${ this._zipRoots.map(zip => zip.sourceUri.path).join("\n") }`)
            }
        });
    }

[justarandomgeek]

Turns out I was making paths with separators the wrong way in some cases. I mangled it wrong consistently, so it looked the same but still failed. Now that I've sorted that out, all my files open correctly! (But the above change was invaluable in debugging this!)