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

Next.js should enforce case sensitivity even if OS doesn't #11742

Closed
Timer opened this issue Apr 7, 2020 · 14 comments
Closed

Next.js should enforce case sensitivity even if OS doesn't #11742

Timer opened this issue Apr 7, 2020 · 14 comments
Assignees
Labels
please verify canary The issue should be verified against next@canary. It will be closed after 30 days of inactivity Webpack Related to Webpack with Next.js.

Comments

@Timer
Copy link
Member

Timer commented Apr 7, 2020

Bug report

Describe the bug

User churn due to:

Module not found: Can't resolve 'next/Head' in '/zeit/628124c9/pages'

To Reproduce

Import next/Head on a case insensitive filesystem and it will work.
Deploy to a sensitive one, it'll fail to build.

Expected behavior

Next.js should never of allowed the build in the first place and suggested the user fix the case sensitivity issue.

@Timer Timer added this to the backlog milestone Apr 7, 2020
@Janpot
Copy link
Contributor

Janpot commented Apr 8, 2020

this PR won't fix this exact case, but it seems related.
🤔 This may be solvable with with a linter as well. Or with case-sensitive-paths-webpack-plugin

@Timer
Copy link
Member Author

Timer commented Jun 6, 2020

Switching this from a bug to feature request due to your PR landing @Janpot 🙏

@Timer Timer added the good first issue Easy to fix issues, good for newcomers label Jun 6, 2020
@CallmeHongmaybe
Copy link

CallmeHongmaybe commented Jul 9, 2020

I was having the same kind of error:
Module not found: Can't resolve '../../../components/Trends' in '/vercel/3e42d29f/pages/country/[category]'

Not sure what I actually did wrong here, even though I'm pretty sure I used correct casing for the component file.

@utiq
Copy link

utiq commented Sep 18, 2020

@CallmeHongmaybe Same issue, how did you solve it?

@sphilee
Copy link
Contributor

sphilee commented Sep 20, 2020

I think this could be useful.

isEnvDevelopment && new CaseSensitivePathsPlugin(),

https://github.com/facebook/create-react-app/blob/master/packages/react-scripts/config/webpack.config.js#L660

@CallmeHongmaybe
Copy link

@utiq I actually haven't solved this yet.

@CallmeHongmaybe
Copy link

CallmeHongmaybe commented Sep 20, 2020

So I'm just gonna put the CaseSensitivePathsPlugin somewhere in next.config.js amirite

@utiq
Copy link

utiq commented Sep 20, 2020

I solved my problem, in my case it was my git configuration, I run this:
git config --global core.ignorecase false

@CallmeHongmaybe
Copy link

@utiq Thanks a lot for the code. I actually took out the --global flag and it worked perfectly.

@Timer Timer modified the milestones: backlog, iteration 12 Nov 2, 2020
@Timer Timer added point: 3 and removed good first issue Easy to fix issues, good for newcomers type: needs investigation labels Nov 2, 2020
@Timer Timer self-assigned this Nov 12, 2020
@Timer Timer modified the milestones: iteration 12, iteration 13 Nov 14, 2020
@timneutkens timneutkens removed this from the iteration 13 milestone Dec 1, 2020
@cbdeveloper
Copy link

cbdeveloper commented May 6, 2021

Can I get an official recommendation whether we should keep git config ignoreCase as true or false in our projects?

My app build was successful on my local environment (Windows) but was failing in Vercel.

I was getting:

Failed to compile Type error: Cannot find module '../../pages/error/ErrorPage' or its corresponding type declarations.

Later I've found out that it was because I'd renamed that path from pages/Error to pages/error. And my git ignoreCase was set to true (I've never chosen that, but I guess git init made that choice for me).

To fix it, I changed git config ignoreCase to false. After that, git created a new untracked file for my ErrorPage module, so I committed that. And then it still wouldn't build, because now I was getting a new error:

Type error: Already included file name '/vercel/path0/app/pages/error/ErrorPage.tsx' differs from file name '/vercel/path0/app/pages/Error/ErrorPage.tsx' only in casing.

So I had to change it to a brand new path name like: pages/error-new/ErrorPage.tsx.

And only then I was able to build it successfully on Vercel.

Later I was able to go back to my desired path name as pages/error/ErrorPage.

Maybe my git config ignoreCase should be set to false from the get go? What do you guys think?

pan93412 added a commit to smhs-os-project/schweb-2.0 that referenced this issue May 31, 2021
@styfle styfle modified the milestones: 11.x.x, 12.0.4 Nov 5, 2021
@vltansky
Copy link
Contributor

Had the same problem.
git config core.ignorecase false (not global) fixed it for me. Thanks @CallmeHongmaybe

@timneutkens timneutkens removed this from the 12.0.5 milestone Nov 17, 2021
@timneutkens timneutkens added Webpack Related to Webpack with Next.js. and removed point: 3 labels Nov 18, 2021
@jankaifer jankaifer self-assigned this Dec 1, 2022
@jankaifer jankaifer added the please verify canary The issue should be verified against next@canary. It will be closed after 30 days of inactivity label Dec 1, 2022
@github-actions
Copy link
Contributor

github-actions bot commented Dec 1, 2022

Please verify that your issue can be recreated with next@canary.

Why was this issue marked with the please verify canary label?

We noticed the provided reproduction was using an older version of Next.js, instead of canary.

The canary version of Next.js ships daily and includes all features and fixes that have not been released to the stable version yet. You can think of canary as a public beta. Some issues may already be fixed in the canary version, so please verify that your issue reproduces by running npm install next@canary and test it in your project, using your reproduction steps.

If the issue does not reproduce with the canary version, then it has already been fixed and this issue can be closed.

How can I quickly verify if my issue has been fixed in canary?

The safest way is to install next@canary in your project and test it, but you can also search through closed Next.js issues for duplicates or check the Next.js releases.

My issue has been open for a long time, why do I need to verify canary now?

Next.js does not backport bug fixes to older versions of Next.js. Instead, we are trying to introduce only a minimal amount of breaking changes between major releases.

What happens if I don't verify against the canary version of Next.js?

An issue with the please verify canary that receives no meaningful activity (e.g. new comments that acknowledge verification against canary) will be automatically closed and locked after 30 days.

If your issue has not been resolved in that time and it has been closed/locked, please open a new issue, with the required reproduction, using next@canary.

I did not open this issue, but it is relevant to me, what can I do to help?

Anyone experiencing the same issue is welcome to provide a minimal reproduction following the above steps. Furthermore, you can upvote the issue using the 👍 reaction on the topmost comment (please do not comment "I have the same issue" without repro steps). Then, we can sort issues by votes to prioritize.

I think my reproduction is good enough, why aren't you looking into it quicker?

We look into every Next.js issue and constantly monitor open issues for new comments.

However, sometimes we might miss one or two due to the popularity/high traffic of the repository. We apologize, and kindly ask you to refrain from tagging core maintainers, as that will usually not result in increased priority.

Upvoting issues to show your interest will help us prioritize and address them as quickly as possible. That said, every issue is important to us, and if an issue gets closed by accident, we encourage you to open a new one linking to the old issue and we will look into it.

Useful Resources

@balazsorban44
Copy link
Member

This issue has been automatically closed because it wasn't verified against next@canary. If you think it was closed by accident, please leave a comment. If you are running into a similar issue, please open a new issue with a reproduction. Thank you.

@github-actions
Copy link
Contributor

github-actions bot commented Feb 5, 2023

This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 5, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
please verify canary The issue should be verified against next@canary. It will be closed after 30 days of inactivity Webpack Related to Webpack with Next.js.
Projects
None yet
Development

Successfully merging a pull request may close this issue.