Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Set up CI on Windows #344

Open
wants to merge 14 commits into
base: main
Choose a base branch
from
Open

Set up CI on Windows #344

wants to merge 14 commits into from

Conversation

lishaduck
Copy link
Contributor

@lishaduck lishaduck commented Feb 21, 2025

Resolves #343.

Should probably fail until #340 gets fixed?

@jfmengels
Copy link
Owner

I agree we should run tests on Windows (maybe on Mac as well?), but I imagine it will increase the likelyhood that we get rate limits (which we still keep seeking for some reason). Should we maybe exclude the template tests on Windows?

@lishaduck
Copy link
Contributor Author

First off, how did I hit rate limits without running it? Must've still got something wrong with #310. I'll take a look ASAP.
Second off, it luckily looks like most of this so far is newlines. A few path issues in test code, but I didn't see any bugs (which are probably in the run tests).

@lishaduck lishaduck force-pushed the windows-ci branch 2 times, most recently from e37d941 to c3c75bf Compare February 22, 2025 23:10
@lishaduck lishaduck changed the title Setup ci on windows Set up CI on Windows Feb 22, 2025
Copy link

socket-security bot commented Feb 23, 2025

New and updated dependencies detected. Learn more about Socket for GitHub ↗︎

Package New capabilities Transitives Size Publisher
npm/[email protected] None 0 51.3 kB danielroe, pi0
npm/[email protected] 🔁 npm/[email protected] Transitive: filesystem +2 130 kB

View full report↗︎

test/run.mjs Outdated
return data.replace(new RegExp(localPath, 'g'), '<local-path>');
return data
.replace(
// eslint-disable-next-line security/detect-non-literal-regexp -- Test code.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not happy about this either. Perhaps we should only enable security on non-test files?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Depends what other rules security holds. I would like it help prevent if people try to do weird code executions for instance. But yeah, a regex like this is fine.

@lishaduck
Copy link
Contributor Author

Wow, pathe is magic! All tests failing to just one failing because Anonymize needs updates.

@@ -383,18 +376,15 @@ function createExtraFilesWatcher(options, app, runReview, onError, request) {
return chokidar
.watch(
request.files.map(
({pattern, included}) =>
(included ? '' : '!') + OsHelpers.makePathOsAgnostic(pattern)
({pattern, included}) => (included ? '' : '!') + pattern
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does chokidar support Windows-style paths?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No idea. I should check. They normalize it (at least they used to, we're still on v3, so they still should?), so you can use either, but it should return a POSIX path rather than a DOS path.
I had a chat with my dad about the elm-review's handling of drives, which basically ended with makePathOsAgnostic uses /.:/ to strip the drive, when elm-review should keep the drive so that you can execute it across drives (which MS wants to make more common). pathe handles proper agnosticism, so the pattern passed in should be correct, but I should also just check that as well.

elm-format doesn't look like it supports lf line endings on Windows.
Also disable remote tests on Windows.
I think this is partly a step in the wrong direction, but we'll see.

Here's what I've found about drive letters:
- On normal Windows, paths are DOS paths, like "C:\path\to\file"
- Except when they're not, like
  - "\\.\C:\path\to\file"
  - "\\?\C:\path\to\file"
- Sometimes Windows uses UNC, which is like "\\hostname\C$\path\to\file"
- On Git Bash, paths are like "/c/path/to/file"
- On Node, paths are like "C:/path/to/file"
- On WSL, paths are like "/mnt/c/path/to/file"

Sometimes drive letters are case sensitive, sometimes they're not.

And that's just for absolute paths.
There's even more weird stuff for relative paths.
Makes me glad to be using macOS so much these days.
Yes, this should be fixed.
No, this should be fixed later.
For now, I need to check the tests.
@lishaduck
Copy link
Contributor Author

@jfmengels, how much do we care about outputting idiomic paths on Windows? Right now, the CLI outputs paths like this: "C:\Somewhere\Foo.txt", but this PR changes that to "C:/Somewhere/Foo.txt", which is equally valid, but could be a slight behavioral change (does that hurt the IDE integration?) and might be confusing to newcomers? (But Windows paths are confusing in general, so maybe they should just get over it, see the writeup at b9c822a).

@lishaduck
Copy link
Contributor Author

@jfmengels, can you take a look a the current failure? I'm not really sure why it's different. Is it an prompts thing? I don't think we're doing anything different.

@lishaduck
Copy link
Contributor Author

lishaduck commented Feb 24, 2025

Is it an prompts thing?

Yup. This is silly code: https://github.com/terkelg/prompts/blob/e0519913ec4fcc6746bb3d97d8cd0960c3f3ffde/lib/util/figures.js

So we could normalize it, we could try inquirer or Clack or something, IDK, maybe we could monkey-patch the characters?
Can Windows really not render the characters by default?

@lishaduck
Copy link
Contributor Author

Can Windows really not render the characters by default?

If I'm reading this old DevBlogs post correctly, UTF-8 support for Windows Console landed in 2018, so it should be fine by now.

@jfmengels
Copy link
Owner

maybe we could monkey-patch the characters?

Yeah, I guess we should... 😞
I would be okay with replacing prompts with a custom thing as well, but that's a bigger task 😅

@jfmengels
Copy link
Owner

how much do we care about outputting idiomic paths on Windows? Right now, the CLI outputs paths like this: "C:\Somewhere\Foo.txt", but this PR changes that to "C:/Somewhere/Foo.txt", which is equally valid, but could be a slight behavioral change (does that hurt the IDE integration?) and might be confusing to newcomers? (But Windows paths are confusing in general, so maybe they should just get over it, see the writeup at b9c822a).

That's a lot of ways to write Windows paths 🤔
I honestly don't know. If they're bot h valid, then either one is fine by me, but since I'm not a Windows dev, I'm not adequately positioned to to tell what is best. I would say that it's probably best to change this only it it is nicer for the user in some way, not if it's just for us running it in CI.

@lishaduck
Copy link
Contributor Author

I would say that it's probably best to change this only it it is nicer for the user in some way, not if it's just for us running it in CI.

Ok, that was my question. I'll see if I can normalize back to Windows for output.

@lishaduck
Copy link
Contributor Author

lishaduck commented Feb 24, 2025

I would be okay with replacing prompts with a custom thing as well, but that's a bigger task 😅

I took a closer look at alternatives. Clack is a very different feel from elm-review's current vibe, I don't think we want to go that way. inquirer also detects windows, but it also supports unicode on modern terminals, so perhaps we could fake the terminal env var in tests to be one that supports unicode? Maybe???
I might need to look into the prior art. Somebody's got to have run into this before.

Honestly, I might just find-replace √ with ✔ for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add Windows CI
2 participants