-
-
Notifications
You must be signed in to change notification settings - Fork 26
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
base: main
Are you sure you want to change the base?
Set up CI on Windows #344
Conversation
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 |
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. |
e37d941
to
c3c75bf
Compare
New and updated dependencies detected. Learn more about Socket for GitHub ↗︎
|
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. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
3623ee3
to
39429b5
Compare
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.
39429b5
to
62928c5
Compare
@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). |
ca83b24
to
a54de65
Compare
@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. |
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? |
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. |
Yeah, I guess we should... 😞 |
That's a lot of ways to write Windows paths 🤔 |
Ok, that was my question. I'll see if I can normalize back to Windows for output. |
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??? Honestly, I might just find-replace √ with ✔ for now. |
Resolves #343.
Should probably fail until #340 gets fixed?