I'm reticent to merge this change even if it does work since we are pointing directly to a git repo and an unreleased sha for source-map.

I think the danger with this approach is that we might forget to replace the unreleased SHA with an official version of source-map as there's nothing prompting us to check for a newer version when we need to switch to Node 18.

Since the ultimate goal of this is to unblock us to use Node 18, I'd be inclined to suggest we wait until we'll need to run on 18 instead of half-heartedly upgrading source-map now. We'll then be prompted to upgrade source-map as part of that process and by that time it's likely an official version will be released.

What do you think?

There's no rush to upgrade right now, but also, the request to upgrade source-map has been open for a while and there still hasn't been a release.

My concern is that when vscode moves to node 18, this extension will be broken until we get a new version of source-map (and fix the other problems). At this point, we're going to need to scramble to fix it fast.

It's hard to tell how often vscode updates its node versions. Maybe every 8 months? And the last time was in March. I don't want to get blindsided by this in the future, but we don't need to fix this now.

@aeisenberg Good news! Looks like a fix was merged into source-map to address the failing build (in Oct 2020): mozilla/source-map#423.

And a new release (0.7.4) containing the fix was pushed 10 days ago, which is quite Nice of them. ;)

I've just tested this (branch) with the steps described in the original issue and the build now works correctly.

Thanks for looking into this. That's good news. Would you mind pushing up your change?

Closing in favour of #1378.