-
Notifications
You must be signed in to change notification settings - Fork 10.3k
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
fix(gatsby-cli): normalize case of windows drive letter #20437
Conversation
@wardpeet Mind reviewing? As you are my companion in the misfortune of using Windows 😃 |
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.
This is solid!
How do I test this? |
@wardpeet Switch to lowercase There is also another repo: https://github.com/murnana/gatsby-bug-repo/tree/feature/gatsbyjs%2319863 which produces webpack warnings on |
dd04841
to
8a0b51d
Compare
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.
Some small nitpicks but this is cool! 😎 Great work
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.
Looks good to me! :) thanks @vladar
Published in |
Hi, I hate to comment on a PR that already fixed this issue #19863 but I'm still getting that error. If there's anything I'm missing here please let me know and thank you in advance. |
Description
This PR ensures that the current working directory on Windows always has an uppercase drive letter (i.e., C: vs. c:).
Motivation
Different utils like "true-case-path", "normalize-path", "slash" treat Windows drive letter differently. "true-case-path" will uppercase, others usually don't care. As a result path normalization produces different results depending on current cwd (c: vs. C:) which manifests in weird issues that are very hard to debug (see related issues bellow).
Ad-hoc fixes like the one introduced in #17492 address the part of the problem but anytime you want to compare a path that is normalized this way you must remember about it and normalize the other side of the comparison the same way.
This is not maintainable (and is especially annoying for those who do not use Windows as they cannot even test it). Things get even worse because we can't really control community plugins or site code but everything should still be working even with a different set of libraries.
This PR is meant to be a general solution to this problem and (hopefully) fix it for good.
Documentation
N/A (as this is a bugfix)
Related Issues
Profiscience/true-case-path#3
#16721
#17811
Fixes #19863