@std/path in the browser has different behavior for Windows users

[alexgleason]

Describe the bug

I am using @std/path in the browser to resolve virtual paths in a virtual terminal on a virtual filesystem, eg:

But when the user uses my website from a Windows computer, everything is broken:

After some digging, I found this:

export function join(path: string | URL, ...paths: string[]): string {
  return isWindows ? windowsJoin(path, ...paths) : posixJoin(path, ...paths);
}

isWindows is defined like this:

export function checkWindows(): boolean {
  // deno-lint-ignore no-explicit-any
  const global = globalThis as any;
  const os = global.Deno?.build?.os;

  // Check Deno, then the remaining runtimes (e.g. Node, Bun and the browser)
  return typeof os === "string"
    ? os === "windows"
    : global.navigator?.platform?.startsWith("Win") ??
      global.process?.platform?.startsWith("win") ?? false;
}

It checks navigator.platform, which means Windows users will get a different paths experience in a browser environment.

But that doesn't make sense in the browser... we are not dealing with a real filesystem. I think it's an unexpected behavior for the functionality to be different between platforms when used from a browser.

EDIT: Also, path-browserify does not have this problem, so switching to that solves my issue.

[lionel-rowe]

The standard way of overriding the default OS detection would be importing from @std/path/posix (or @std/path/windows) instead of @std/path.

I think it's an unexpected behavior for the functionality to be different between platforms when used from a browser.

Hmm... possibly? But there are browser-centric use cases where you'd want the detection, e.g. when interacting with file system access APIs.