refactor: replace try-import with globalThis.process

[rtritto]

No description provided.

[brillout]

Isn't checking after node:http more precise and thus better?

[rtritto]

Because the node:http is an hack while globalThis is more cross-platform (window (Browser) + self (Web Worker) + global (Node.js)) and more consistent.

[brillout]

Precisely, ins't checking after node:http more accurate? What we want here is to check whether the environment supports connect handlers which is only supported in Node.js. For that purpose checking after node:http seems a lot more accurate, right?

[rtritto]

What we want here is to check whether the environment supports connect handlers which is only supported in Node.js

You can simply check if you are in the Node.js environment.

Some points to prefer the globalThis approach:

• it's not hacky
• it's not an async/await function
• gains in performance
• uses native check related to the environment

Absurdly, the user can install a library called node:http.

[brillout]

The issue with globalThis.process !== undefined is that it isn't reliable. For example, any library could be defining globalThis.process and consequently break vike-node. So I still think checking whether node:http exits to be more reliable. Closing, but let's see if we stumble upon a real world issue with the node:http check and I'll then re-consider this.

[rtritto]

As alternative you can enforce with:

export function isNodeLike() {
  return globalThis.process !== undefined && globalThis.process.versions?.node !== undefined
}

Some source: https://www.30secondsofcode.org/js/s/is-node-or-browser

[brillout]

I ain't sure it catches Bun or Deno then.

[rtritto]

I ain't sure it catches Bun or Deno then.

We can use instead:

export function isNodeLike() {
  return (
    globalThis.window === undefined &&
    globalThis.document === undefined &&
    globalThis.navigator === undefined
  )
}

[brillout]

I think it's better we check for capability instead.