Revert "Fix importing @tauri-apps/api in Node.js"

[amrbashir]

Reverts #3752

[JonasKruckenberg]

I must admit, I have not been following along with this, but the problem of the original PR was that it introduced unexpected behavior correct?
What was it trying to solve in the first place though? Because we have been doing quite a lot of testing in the context of #3437 that should allow people to use Tauri APIs in nodejs already 🤔 except for @tauri-apps/api/window which requires async import as discussed previously.

Edit: Also, @amrbashir just a heads up that your commit is not signed

[amrbashir]

What was it trying to solve in the first place though?

It was trying to solve regular imports in SSR environments like SvelteKit.

but the problem of the original PR was that it introduced unexpected behavior correct?

Yeah, if your SSR server is running on Linux and your app is running on Windows, isLinux() will always be true while isWindows() is false and any HTML rendered on the server that uses sep, delimiter, EOL constants (Which is where isLinux() and isWindows() is used) will render for Linux instead for Windows.
I can't say this enough, Tauri APIs are designed for client-side usage and shouldn't/can't be used in SSR at all. If you must use SSR, It should be async imported and executed in the client.

Edit: Also, @amrbashir just a heads up that your commit is not signed

you'd think github would sign your commits when clicking "revert" on a commit but they don't 🥲.

[probablykasper]

The problem is that the PR checks what OS it's running in Node.js, which could result in that OS being used as part of SSR, and it could result in incorrect sep, delimiter or EOL values if the server and app are in different OS-es.

The point of the PR was to prevent errors when importing @tauri-apps/api, and if you're calling some API for example, the error would instead show up where you're calling that API.

I don't know if I agree that this is unexpected behavior though. If Node.js happened to have the same API as browsers, would we have to deliberately detect if we're running Node.js and throw an error to prevent unexpected behavior?

[amrbashir]

I don't know if I agree that this is unexpected behavior though. If Node.js happened to have the same API as browsers, would we have to deliberately detect if we're running Node.js and throw an error to prevent unexpected behavior?

No, We shouldn't care about Node.js at all because it is not the actual runtime and maybe your SSR is using another runtime like deno or Bun.js and we shouldn't care about them either.

Our current published api will throw an error because window is undefined and that is enough, that is the expected behavior and users should know by then that this API should be used client side. All we need to do is to point them to a FAQ and that's it.

[lucasfernog]

I agree with Amr here. I totally missed this point on the other PR.

[JonasKruckenberg]

I agree that SSR/SSG support is nothing the API should be overly concerned with. It might communicate the wrong things to users too if it did.

But wouldn't adding a mockOS function to the mocks module solve this problem? Users could pick their user agent strings even 🤔

[amrbashir]

Sure, adding a mockOS() is fine. It can be added in another dedicated PR though.