When I run npm run dev. out of the blue, localhost just loads forever. The response is below in image 1:
I thought it was some sort of change I made, but I exhausted myself looking for a change that could have caused it. I then duplicated my repo from Github (in which localhost worked fine), manually added all my changes to the duplicate, and then deleted all the changes on my original repo. I then added the changes one-by-one back to the original from the duplicate.
Since then, everything was working fine. But today, I pushed changes to Github, and renamed my root folder, and immediately after, the stalled response has come back. No code changes caused this, and it's definitely not that I renamed the folder, because it happened yesterday before I renamed anything.
I think it must be a Next issue, but I can't be sure. I have deleted the .next folder, node_modules, and package-lock.json, and reinstalled, but that has not worked. I've also restarted VSCode and my computer.
Next has run and compiled successfully (as image 2 shows).
The problem was I had installed #apollo/client version 3.5.6, which for some reason was breaking everything. I downgraded to 3.4.0, and it's working again. Thanks, GH commit history.
Related
I understand that this issue has been raised numerous times, but I have tried almost all solutions available with no success. The thing is that I am capable of deploying to GitHub pages with no problem, but Heroku mentions I have some routing issue.
After the recent issue whereby Heroku removed Github integration with Heroku, I have been having trouble pushing code. Initially, my website worked fine, with automatic deployment via Github. However, when I try manually pushing via:
$ git add .
$ git commit -am "make it better"
$ git push heroku master
I am facing this error:
Module not found: Error: Can't resolve './pages/MainPage' in '/tmp/build_8986ef5f/src'
I have tried removing this page, and the error will just change to another can't resolve path error.
My file directory is:
- build
- node_modules
- public
- src
- pages
- MainPage.js
- SecondPage.js
- ...
- App.js
- index.js
.gitignore
package-lock.json
package.json
Within the App.js file, I import the library through a relative path via:
import Home from './pages/MainPage';
Is there something wrong with my relative pathing? I have not changed the structure since deploying via Github so I don't know what's the error.
I've found out the error. Apparently deploying to Github had resulted in some case-sensitive naming to go wrong. E.g. although I was deploying it as MainPage, it was deployed as mainpage for some reason.
This had resulted in being unable to find the file path.
I used:
heroku run bash
To figure out the error of naming convention. To fix it, I removed all affected folders with wrong casing deployment, committed changes, then readded them in and redeployed it. It worked after I did this.
Thank you #dfwgwefewfwe! I don't have enough reputation to comment on their post, but it definitely fixed it for me.
Just to add some extra information though for others that may be stuck with it:
My issue was that I had some assets that were in folders such as
Equipment
/hands
/gloves1.png
/gloves2.png
/feet
/boots1.png
/boots2.png
To make things more consistent, I just capitalized the first letters to be Hands and Feet
I ran that command
heroku run bash
and was able to find those folders that had been renamed, and they were still in their old version.
So back on my local copy, I moved the whole Equipment folder to another location, removed any references to the assets in the code, and pushed that up to heroku.
Now the Equipment folder was removed on the server, then I was able to revert my last git commit and push exactly what I was trying to push before and it worked.
I hope that this helps someone else!
So I am working with NextJs and facing random behavior. Once the application runs successfully, I do development and push code to Github. The next day I again run the app using npm run dev and face this.
So then I had to remove the repository and reset it again to make it work. But now today I am facing this again. I successfully worked yesterday, pushed the code to the git, and when I run this today I again face this error.
This seems to be something wrong with NextJS. Can anyone point out the cause?
For anyone else facing this annoying issue, #Pranta has already covered it. If it is random for you, and you aren't mapping anything, just do the following:
Delete the node_modules directory
Then npm install again.
I recently added google tag manager on a react-app I'm working on and pushed it in a branch called gtm.
AWS Amplify builds the app successfully and it's up and running. I then merged these changes in the master branch with no merge conflicts. However, in the master branch, (where it's hosted on a custom domain) the app fails to build due to this error:
Error: [BABEL] /codebuild/output/src957941865/src/webapp/src/index.js:
Cannot find module '#babel/helper-regex'
Below is the build error displayed in AWS Amplify
(1) First thing to do was obviously perform this:
yarn add #babel/helper-regex
However, deploying with the new changes only creates another
Error: [BABEL] /codebuild/output/src957941865/src/webapp/src/index.js:
but with a different babel module instead, so this creates a long chain of adding packages that don't necessarily fix the underlying issue.
(2) Second fix I did was revert to a version of the app that was successfully deployed. I initially suspected that the google tag manager was the one causing the problem. However, it wasn't the case. The same error was displayed.
(3) Third thing I did was I referred to fix suggested in this issue (https://github.com/facebook/create-react-app/issues/8062). Summarizing the thread, it says that all I needed to do was to perform the following.
Delete node_modules
Delete yarn.lock
Perform yarn install
Unfortunately, this didn't solve the issue and the build error still persists.
(4) Fourth fix I did was I checked the differences between the two branches master and gtm using git diff master..gtm and here was the result.
Seeing that there were differences, out of desperation, I downloaded the **gtm** branch and then copy pasted its contents into the master branch in windows explorer then committed the changes.
Unfortunately, this still didn't fix the issue.
The only thing I haven't tried yet is reconnecting the master branch in AWS amplify but I don't want to risk the website not working since there are active users and if I ever go through with it and it still didn't fix the issue it'll cause more inconvenience. I hope someone already experienced this before and can point me to the right direction.
I had a similar issue recently while tackling a dependency problem for babel-loader with storybook and create-react-app.
After I noticed other preview builds were working correctly, while having the same code as the master branch, I suspected the node_modules cache was the culprit.
I don't know if there's an easier way of cleaning the node_modules cache that amplify uses internally (searched a bit and found nothing), so I just added an extra command in the preBuild phase (rm -rf node_modules)
eg.
version: 1
frontend:
phases:
preBuild:
commands:
- rm -rf node_modules
- yarn install
Once the build was passing, and the cache is regenerated (this is the last step of the build process) you can simply remove the added command and everything works as expected for future builds.
I suggest you also try combining fixes (2) & (3). That is, revert to a version w/out google tag manager followed by a yarn clean-install (i.e. delete node_modules & yarn.lock -> yarn install). The reason for this is your local workspace may still have broken yarn dependencies from the gtm branch even after you revert to a known-good version.
I started a new developer role a few days ago and made some environmental changes to adapt for work. Since then, my hot reload/fast refresh has just stopped working entirely. Changes don't show up even if I refresh the page manually. Only shows changes when I stop the dev server and restart it with 'npm run dev'. The triangle indicator at the bottom right should be active, showing active reload of the window (this no longer shows up consistently either, and if it does the page gets reloaded, but alas the proposed changes aren't visible)
Context:
It has this effect on all NextJS and react applications of mine. Even running a basic project template off the NextJS examples page shows no hot reload working.
I researched this issue and it seems wrong imports (e.g. importing components using lowercase or files in the pages directory being capitalized) can cause this, but I combed through the code and can't spot any issues (of course, I could be missing it but my codebase is over 300 files).
Service workers in the background can cause issues, but I cleared my browser of all of them to be sure and it still doesn't fix it.
I installed ngrok for tunneling for work purposes and docker-compose to handle the work dev. environment.
Made sure I'm using the latest Next version. Even deleted node_modules and ran npm install. Deleted .next and the out folder and still no luck.
Anybody have any ideas or clues to what I should try next? Is it related to the stuff I installed for work? Something related to VS code or WSL2? Seems so puzzling it kind of just happened overnight. Thanks for any insight or advice!
System information
OS: Windows (WSL2 virtualization for VS code)
Browser: Chrome
Version of Next.js: 10.0.3
Version of Node.js: 14.8.0
Deployment: npm run dev for development work; amplify publish for AWS hosting
The problem is with WSL2. I use WSL2 inside VS Code; which is a big performance upgrade in the Linux environment. The problem is WSL2 is actually in a 'virtualization' and thus cannot send information from VS Code AND the browser (localhost:3000) at the same time.
It's a big issue they are working on and there is no fix yet for it. That's why fast refresh doesn't work because localhost is not receiving the changes being made. Either proxy through or revert back to WSL1 https://github.com/microsoft/WSL/issues/4769
Solution provide by OP on question section
Add a .env file or a .env.local file to your root and put this line on it:
WATCHPACK_POLLING=true
Now, restart your server.
Thanks I encounter the same issue with WSL2. I just switch to windows terminal and it works.
If you run Poweshell as administrator and run
wsl.exe -l -v
This will give you th eversion of wsl your distros run on.
I am personally using Ubuntu, and this is the output
Ubuntu Running 2
docker-desktop Stopped 2
docker-desktop-data Stopped 2
To switch to wsl 1,
Run
wsl.exe --set-version Ubuntu 1
and if you wanna switch back,
run,
wsl.exe --set-version Ubuntu 2.
This worked for me.
In my react projects, I just add in my .env file at the root project folder the values
FAST_REFRESH=false
CHOKIDAR_USEPOLLING=true
and it works! enjoy!
The problem is with WSL2. I use WSL2 inside VS Code. But React JS and Next JS projects don't auto-reload. So, add a .env or .env.local (recommended) file to your root and put these lines on it:
WATCHPACK_POLLING=true
CHOKIDAR_USEPOLLING=true
Now, restart your server.
If you go you https://packagist.org/packages/geekality/website and compare it with what you get when you run `composer show geekality/website.
Latest version at packagist at the top is v0.7
Latest version given in command line output is v0.6
Latest version should have been v0.7.1 in both cases
Version >= 0.7 doesn't even show up in the command line
The dev-master version points to v0.5 ??
What is going on here? How do I fix this? If I change my composer.json to target version/tag 0.7.1, which to me clearly exists on both packagist and on GitHub, I get an error message saying the requested package could not be found.
I have tried
Delete vendor folder and re-update
Delete the composer cache
Do the composer update on a different computer
Delete and recreate the package on Packagist
Create and push a new tag (0.7.1 is basically same as 0.7)
Anyone have any idea what's going on?
Update
Seems like this is caused by some issues with Packagist and that nothing is actually wrong on my side (or others who seem to have the same problem).
I "solved" it temporarily by listing the source of problematic repositories manually in composer.json.
The solution in this case was to wait for Packagist to not be broken.
So, if anyone else have this issue and they have checked all their stuff, maybe check twitter or something to see if anyone else are having issues.
It looks like you stuffed up either your tags or moved origin/master back to an earlier version.
It is version v0.5 that still has the origin/master and master tags associated with it which is very odd.
I think you want to just reset master to the lastest commit, however you probably ought to figure out how this happened first, in case there's something even weirder going on.
The way I tag versions is:
Check in and push everything to the remote repository.
Run git tag 1.2.3 on a command line.
Push the tags on the command line git push --tags
I think you may have caused this issue by skipping step 1 and still having uncommitted changes locally. If you can push those commits, that might fix the problem, otherwise you may need to reset the head to the appropriate version.
In Atlassian Sourcetree that can be done by right clicking on the appropriate checkin, otherwise you can do it from the command line with the git reset command:
git reset --soft a4ed43d16ecb20aaa275ee120e073e043190e093
Does not touch the index file nor the working tree at all (but resets
the head to , just like all modes do). This leaves all your
changed files "Changes to be committed", as git status would put it.
That should not delete anything either locally or remotely, but just change where the head is pointing to.