Define a CaseSensitivity type instead of using useCaseSensitiveFileNames bool
This feels less difficult to think about...
This doesn’t really feel necessary to me 🤷 I think isCaseSensitive (a better name for the same bool) sounds very understandably like a true/false file system property, personally.
The reason I'm not a fan is that case insensitivity is the "weird" case, yet it's the one we treat as the default of false. I have a really hard time remembering which sensitivity true or false is just by reading.
I don’t think that’s right—Windows and macOS are case-insensitive, making the default of false correct for the vast majority of users.
I don’t think that’s right—Windows and macOS are case-insensitive, making the default of
falsecorrect for the vast majority of users.
It's not about the number of users (obviously Windows/macOS outshadows Linux for dev machines, though not CI), but about how often we need to special case things in our code. If we're doing something with the bool it's almost always a case of if !useCaseSensitiveFileNames { // do complicated thing }.
How does this PR change that? https://github.com/microsoft/typescript-go/pull/108/files#diff-bc9badf529b541b86d6fda311f6e0b75b5afcd6d1c9c672d7e3a24454c4aca0cR604
I guess it doesn't, since I didn't take it that far and reverse conditions.
I guess my point isn't super great if you can see from the variable name what it is, but mainly when I was working on the FS stuff, I was having trouble writing tests where I couldn't remember what true/false meant when passing things in, where a named value was a better argument to the call.
If this seems pointless, I can just drop it.
I think the point is not so much just the naming, but more that when you pass the thing in, it's clear what you're passing in. If we have 2 boolean parameters in a row, you'll never have a hazardous refactoring. I personally think it's nice to have the safety of a distinct type.
I'll reopen, but it's entirely possible that this would be moot as most places which set this flag by hand are already written...