Compatibility with Windows

[openscript]

Analysis

The main problem is that the paths are mixed up in inlang. Node implements node:path/posix and node:path/win32. Inlang treats all paths as posix paths. There are other smaller incompatibilities.

Challenges

• Execution (e.g. tests) on Windows
  • Everything handing a path with a Windows drive letter (D:/) to node:fs fails: see https://github.com/inlang/inlang/actions/runs/5378092929/jobs/9757434127
  • Everything handing forward slashed to node:fs on Windows fails
• ide-extension: somewhere there is an error related to this, where a non Windows path is handed to VSCode FS
  • Extension fails to open config #904
  • VS Code Extension: command 'inlang.extractMessage' not found #933

Improvement

These errors shouldn't be hard to fix, but are cumbersome.

• Conversation from something like import.meta.url to a path fails when used with node:fs or VSCode FS on Windows. node:path adds automatically the current drive letter on path.join, which should be utilized. We need to remove the drive letter from the string before. It seems like there is nothing built into node:path or node:fs related to this, so we have to do it by our self.
• Currently path and file system operations are combined (like https://github.com/inlang/inlang/blob/c8bec3f5ebc0cd34969a4728b342179789794dcf/source-code-git/fs/src/implementations/implementations.test.ts#L50). This should be split up (separation of concern) like it's implemented in node.
• Inline environment variables are not supported by Windows Shell: https://github.com/inlang/inlang/blob/4e769d4750ad89d5da0785110241b9f86a8cc859/source-code-git/client/package.json#L24

Discussion

• Besides providing a FS via inlangs environment, also path handling should be abstracted into the environment.
• How should we continue forward with compatibility for Windows?

[felixhaeberle]

@inlang/lisa tagging the lisa team because this currently causing a bug in the IDE extension.
It could be helpful to have a short call to discuss further steps?

[araknast]

Besides the tests is this lisa related? memoryFs is isolated from whatever the host filesystem is, so there should be no issue unless paths are being passed between them for some reason.

As for the mock server and isomorphic-git tests, that should hopefully disappear soon as @project-lisa/client is developed.

[openscript]

I agree, but I never talked about memfs. To exclude some tests from being run on certain platform, we don't have the infrastructure, currently.

[samuelstroschein]

@openscript Inlang treats all paths as posix paths.

Can you clarify what you are referring to with "inlang" here. Project lisa? Memory fs? The dev environment?

• However memoryfs is implemented shouldn't lead to bugs on Windows as all file system operations never hit the OS (in memory).
• Making the dev environment work on windows -> devcontainers (not worth it IMO). The team works on Mac and Linux.

[openscript]

Can you clarify what you are referring to with "inlang" here. Project lisa? Memory fs? The dev environment?

Different places inside the inlang/inlang repository like: fs, plugins, #904, #933

However memoryfs is implemented shouldn't lead to bugs on Windows as all file system operations never hit the OS (in memory).

I agree, but I'm not talking about the memfs.

Making the dev environment work on windows -> devcontainers (not worth it IMO). The team works on Mac and Linux.

In my opinion a development environment should be close to the testing environment, otherwise it would be hard to make proper tests. The testing environment should be close to the production environment or you wouldn't tests the reality.

So is Windows a supported platform of inlang? Which parts of inlang should run on Windows? If it's the ide-extension.. then all dependencies of it (including the plugins) should be tested and running on Windows.

[samuelstroschein]

So is Windows a supported platform of inlang? Which parts of inlang should run on Windows? If it's the ide-extension.. then all dependencies of it (including the plugins) should be tested and running on Windows.

Good argument.

Besides inlang, leaking non-posix file paths into project lisa seems to be a mistake though because complexity would grow. In other words, project lisa should only expose posix file paths to simplify the surface API.

[openscript]

It's not only non-posix and posix paths. There are also URLs in the mix, sometimes used as (new URL(...)).pathname. This is also dangerous (query params, ...), because not always URLs and posix paths can be used interchangeably. Some errors are already caused by this.

[samuelstroschein]

There are also URLs in the mix, sometimes used as (new URL(...)).pathname. This is also dangerous (query params, ...), because not always URLs and posix paths can be used interchangeably.

Well, this seems to be the root cause of the issues then, see nodejs/node#37845.

Frankly, a limitation of emerging web standards and using files in web standard context. Anyhow, can someone fix the import.meta calls?

[samuelstroschein]

Decided on a call with @openscript:

• make cli and ide extension windows compatible, not the entire codebase, to reduce the effort
• test plugins for windows (because they will run in a windows codebase)

@openscript if the summary is correct, please mark this reply as "answer" and close the discussion :)

[openscript]

We also need to make the dependencies of ide-extension compatible: