be agnostic with respect to path separators in path transforms

[softwareCobbler]

Ideally, a transforms like

{
    "idePrefix": "${workspaceFolder}/web",
    "serverPrefix": "/var/www"
}

and

{
    "idePrefix": "${workspaceFolder}\web",
    "serverPrefix": "/var\www"
}

would be, from the point of view of the user, functionally identical.

[softwareCobbler]

For comparing files, we now (as of 2.0.13.2) do canonicalize \ and / to just /. But when spitting out file names back to the client, I think we have to respect what the transform says verbatim, because we don't know what the "right" separator to use is. Now, we could offer an option, that says, "use this separator", but that's not too different from requiring the path separator to be correct in the first place. Alternatively, we could ask the DAP client's runtime what it is, using whatever platform primitives they offer. But then we're getting into spooky action at a distance, and would probably end up needing to offer an option to not do that, and on it goes.

With the canonicalized comparisons, it's more likely that a file gets a match on the server and we send something to the client, where if the path sep in the transform is wrong, the client will try to open that file, and report an error like "cannot open file foo\bar/baz.cfm", which a user would be able to notice: "huh? That's a file on my system! Oh, I see, the path sep is wrong, let me patch that transform up". Which is an improvement over the current behavior of just not matching anything.

[dave-se]

Thanks for raising this issue — my team recently started using this tool and it’s already been a huge time-saver. We develop primarily on Macs but target Windows VMs, so we ran into this exact problem with path mismatches due to differing separators.

We maintain a large legacy CF codebase, and having to patch transforms manually across all files quickly became unmanageable. To help with that, I opened a PR to introduce a pathSeparator option on the client side: #72 — it allows you to explicitly control the output path separator when sending file paths back to the client.

This keeps the default behavior unchanged but gives teams like ours an easy way to standardize things in cross-platform setups. Happy to take feedback or adjust if there’s a better way to integrate it!

[jamiejackson]

What's the downside of defaulting to auto?

[dave-se]

I started with auto but landed on none to be backwards compatible for users where this isn't a challenge even though they should not see a functional difference. Certainly open to adjusting!

[jamiejackson]

My personal vote is for auto as the default. It feels like more of a bug fix than an option. I think it's enough that anybody with some strange corner case could use some other option. IOW, focus on the 99% but accommodate the 1%.

Besides, this is just a dev tool, so we're not going to take down someone's site down by foregoing strict backwards-compatibility.

Just my 2¢.

[dave-se]

That's a fair point! I went ahead and made that adjustment.