I setup a new project using Yarn and NextJS on my Windows machine today. Upon start-up, I get an error that the casing is "invalid" for my project directory. Specifically, I am seeing the following errors:
Invalid casing detected for project dir, received c:\super-amazing-project actual path C:\super-amazing-project
There are multiple modules with names that only differ in casing.
The kicker is that in the error message the two paths are identical except for the drive letter.
How do I fix this?
Versions
Yarn version 1.22.17
NextJS version 12.1.5
Console output
c:\super-amazing-project>yarn dev
yarn run v1.22.17
$ next dev
warn - Invalid casing detected for project dir, received c:\super-amazing-project actual path C:\super-amazing-project, see more info here https://nextjs.org/docs/messages/invalid-project-dir-casing
ready - started server on 0.0.0.0:3000, url: http://localhost:3000
./node_modules/react/cjs/react.development.js
There are multiple modules with names that only differ in casing.
This can lead to unexpected behavior when compiling on a filesystem with other case-semantic.
Use equal casing. Compare these module identifiers:
* C:\super-amazing-project\node_modules\react\cjs\react.development.js
Used by 2 module(s), i. e.
C:\super-amazing-project\node_modules\react\index.js
* c:\super-amazing-project\node_modules\react\cjs\react.development.js
Used by 2 module(s), i. e.
c:\super-amazing-project\node_modules\react\index.js
package.json
{
"name": "super-amazing-project",
"version": "0.1.0",
"private": true,
"scripts": {
"dev": "next dev",
"build": "next build",
"start": "next start",
"lint": "next lint"
},
"dependencies": {
"#chakra-ui/react": "^1.8.8",
"#emotion/react": "11",
"#emotion/styled": "11",
"framer-motion": "6",
"next": "12.1.5",
"react": "18.0.0",
"react-dom": "18.0.0",
"react-icons": "^4.3.1"
},
"devDependencies": {
"#types/node": "17.0.25",
"#types/react": "18.0.6",
"#types/react-dom": "18.0.2",
"eslint": "8.13.0",
"eslint-config-next": "12.1.5",
"typescript": "4.6.3"
}
}
You probably changed the case of the drive letter on Windows in the command terminal by using a command like cd c:\super-amazing-project and then setup a project with a lowercase Windows drive letter. This causes strange issues like the ones you're experiencing.
Solution 1. Change the case of the drive letter and try yarn dev again
You can change the case of the drive letter on Windows using the cd command like this
C:\super-amazing-project>cd c:\
c:\>cd super-amazing-project
c:\super-amazing-project> yarn dev
Solution 2. Setup your project again using the default uppercase drive letter
Installing with the non-default lowercase drive letter on Windows may have placed your new project in a bad state. If this project is fresh, it may be easier to just run npx create-next-app again and copy your project files.
Related
I just have a question around best method to start my react app when I run cypress test. Right now the way its setup for me I need to start my server then run cypress test. I would like a single command to start react app -> run Cypress test.
I am new to both react and cypress
My package.json looks like this
"scripts": {
"start": "react-scripts start",
"build": "react-scripts build",
"test": "cypress run",
"eject": "react-scripts eject"
},
Currently I need to run npm start then in another window npm test
I tried to start and run test in a single line but I could not get it to work. It just started react app and did nothing else.
I wrote this up recently as part of a series on TDD in JS, you can read the full article on my blog.
First, install some useful helper dependencies:
$ npm install concurrently cross-env wait-on
Then add some extra scripts to the package.json:
"e2e:ci": "concurrently -k -s first \"npm:e2e:ci:*\"",
"e2e:ci:app": "cross-env BROWSER=none PORT=4321 npm start",
"pree2e:ci:run": "wait-on -t 30000 http-get://localhost:4321",
"e2e:ci:run": "cross-env CYPRESS_BASE_URL=http://localhost:4321 npm run e2e",
So what does that do? When we run npm run e2e:ci, the concurrently script is going to run two things in parallel for us:
e2e:ci:app: Run the app using npm start, with some environment variables set via cross-env (this allows it to work on *nix and Windows):
BROWSER=none stops the browser from popping up and taking over the screen [this is the default behaviour of a React app created by CRA, which the article was using]; and
PORT=4321 runs the app on the specified port (so we can still have a version running on port 3000 without causing any conflicts).
e2e:ci:run: Run the E2E tests in a two-step process:
The pre script runs first, and uses wait-on to wait for up to 30,000ms for the app to be running on the specified port; then
If that works (i.e. the app starts in less than 30s) run the actual tests, with the baseUrl configuration overridden to point to the right place.
The other configuration options passed to concurrently itself are:
-k, meaning stop all of the other processes when one exits (in this case we expect our tests to exit at some point and want to stop the app when they do); and
-s first, meaning that the output of the overall command is the output of the first one to exit (i.e. output from the e2e:ci command should be the output from the tests).
Building on the answer by jonrsharpe, I also needed to launch my (golang, though the implementation language doesn't really matter) api server, and I'm running tests via wdio. It uses the same toolset as his answer but with an extra step:
"e2e:ci": "concurrently -k -s first \"npm:e2e:ci:*\"",
"e2e:ci:server": "cross-env SERVER_PORT=40001 ./launchServer.sh",
"pree2e:ci:app": "wait-on -t30000 http-get://localhost:40001/state",
"e2e:ci:app": "cross-env BROWSER=none PORT=40002 npm start",
"pree2e:ci:run": "wait-on -t 30000 http-get://localhost:40002",
"e2e:ci:run": "npx wdio run ./wdio.conf.js --baseUrl http://localhost:40002"
The two extra scripts are:
e2e:ci:server which runs a script to launch the server
pree2e:ci:app just waits until the server is running. Note that it's not just waiting on "/" -- my api server 404s on root requests, and wait-on needs to get a 2xx response, so the http-get url needs to be a valid api endpoint ("/state").
It's also worth noting that wdio just uses an extra command line argument to set the base url instead of the env var in the original cypress solution.
The issues I am having the past few days is that I can not update my
https://filipzafran.github.io/Best-TO-DO-App-in-the-history-of-the-universe/ website page.
Although the gh-pages branch is updated with the new code, it still shows the old one.
I have:
- deleted and created again the gh-pages
- pushed a new commit
- re-merged with master
- cleared browser history (catche)
- read numerous solutions
Still cant make it publish the new code on my gh-pages website.
I feel like there might have to do with depolyment.
Do I need to deploy again?
Because when I do, from master, it gives me a long error:
redux-todo-step_by_step git:(master) npm deploy
Usage: npm <command>
where <command> is one of:
access, adduser, audit, bin, bugs, c, cache, ci, cit,
clean-install, clean-install-test, completion, config,
create, ddp, dedupe, deprecate, dist-tag, docs, doctor,
edit, explore, fund, get, help, help-search, hook, i, init,
install, install-ci-test, install-test, it, link, list, ln,
login, logout, ls, org, outdated, owner, pack, ping, prefix,
profile, prune, publish, rb, rebuild, repo, restart, root,
run, run-script, s, se, search, set, shrinkwrap, star,
stars, start, stop, t, team, test, token, tst, un,
uninstall, unpublish, unstar, up, update, v, version, view,
whoami
npm <command> -h quick help on <command>
npm -l display full usage info
npm help <term> search for help on <term>
npm help npm involved overview
Specify configs in the ini-formatted file:
/home/ficho/.npmrc
or on the command line via: npm <command> --key value
Config info can be viewed via: npm help config
npm#6.14.7 /home/ficho/.nvm/versions/node/v13.8.0/lib/node_modules/npm
Did you mean this?
repo
This is my repo.
Assuming you have a deploy script in your package.json, to successfully execute it you have to type in npm run deploy as deploy isn't an npm command per se.
In npm, run is the command that allows you to execute your custom scripts.
Here's an example of a package.json and relative commands...
{
"name": "raci-api",
"version": "0.4.0",
"description": "raci API",
"main": "src/server.js",
"scripts": {
"start:dev": "nodemon src/server.js -e \"NODE_END=development\"",
"start:production": "node src/server.js -e \"NODE_ENV=production\"",
"lint": "eslint src/**/*.js",
"lint:fix": "eslint --fix src/**/*.js",
"docs:serve": "npx http-server -c-1 docs -o",
},
"author": "",
"license": "ISC",
"repository": {
"type": "git",
"url": "yourRepoURL"
},
"dependencies": {
"yourDependencies": "here"
},
"devDependencies": {
"yourDevDependencies": "here"
}
}
In this case, to properly serve the app (E.G. in loopback) you have to use npm run start:dev.
I have a fairly simple web application based on the Visual Studio "React" template. When I run MSBuild, it runs an npm install and then calls webpack to create a Javascript bundle. When I build this locally, the app runs fine. When I build this in a DevOps pipeline, the home page is a blank white page with script errors in the console:
I doubt the error really matters much and I wouldn't even begin to know where to start tracking it down anyway. However, after quite a bit of investigation here's what I know so far:
The source code I'm building locally and the source code DevOps is building is exactly the same.
I've verified package.json and package-lock.json are exactly the same.
I've done a diff on the node_modules directory locally and on DevOps. Every single file in every single directory is exactly the same. I'm npm installing the same exact versions of everything.
Both my local machine and DevOps is using node 12.10.0
It's not the web server. If I zip up my locally built files and upload them to to the web server, it works.
Here's my package.json file:
{
"name": "LimeadeDocs",
"version": "0.1.0",
"private": true,
"dependencies": {
"bootstrap": "^3.4.1",
"core-js": "^3.1.4",
"js-yaml": "^3.13.1",
"mobx": "^5.13.0",
"mobx-react": "^6.1.3",
"react": "^16.9.0",
"react-bootstrap": "^0.31.5",
"react-dom": "^16.9.0",
"react-is": "^16.9.0",
"react-router-bootstrap": "^0.24.4",
"react-router-dom": "^4.2.2",
"react-scripts": "1.0.17",
"redoc": "2.0.0-rc.14",
"rimraf": "^2.6.2",
"styled-components": "^4.4.0",
"swagger-diff": "^0.6.0"
},
"scripts": {
"start": "rimraf ./build && react-scripts start",
"build": "react-scripts build",
"test": "react-scripts test --env=jsdom",
"eject": "react-scripts eject"
}
}
Here's my DevOps build pipeline:
trigger:
- master
pool:
vmImage: 'windows-latest'
variables:
buildConfiguration: 'Debug'
steps:
- task: UseNode#1
displayName: 'Install Node 12.10.0'
inputs:
version: '12.10.0'
- task: NuGetCommand#2
displayName: 'Restore NuGet Packages'
inputs:
command: 'restore'
restoreSolution: './LimeadeDocs.sln'
- task: MSBuild#1
inputs:
solution: './LimeadeDocs.sln'
platform: 'Any CPU'
configuration: '$(BuildConfiguration)'
msbuildArguments: '/t:publish'
- task: PublishBuildArtifacts#1
displayName: 'Publish Build Artifacts'
inputs:
PathtoPublish: '$(Build.SourcesDirectory)/LimeadeDocs/bin/$(BuildConfiguration)/netcoreapp2.1/publish/'
ArtifactName: 'Website'
condition: succeededOrFailed()
Here's the CSPROJ file it's building:
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>netcoreapp2.1</TargetFramework>
<TypeScriptCompileBlocked>true</TypeScriptCompileBlocked>
<TypeScriptToolsVersion>Latest</TypeScriptToolsVersion>
<IsPackable>false</IsPackable>
<SpaRoot>ClientApp\</SpaRoot>
<DefaultItemExcludes>$(DefaultItemExcludes);$(SpaRoot)node_modules\**</DefaultItemExcludes>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.App" />
<PackageReference Include="Microsoft.AspNetCore.Razor.Design" Version="2.1.2" PrivateAssets="All" />
<PackageReference Include="Microsoft.AspNetCore.SpaServices.Extensions" Version="2.1.1" />
</ItemGroup>
<ItemGroup>
<!-- Don't publish the SPA source files, but do show them in the project files list -->
<Content Remove="$(SpaRoot)**" />
<None Include="$(SpaRoot)**" Exclude="$(SpaRoot)node_modules\**" />
</ItemGroup>
<Target Name="DebugEnsureNodeEnv" BeforeTargets="Build" Condition=" '$(Configuration)' == 'Debug' And !Exists('$(SpaRoot)node_modules') ">
<!-- Ensure Node.js is installed -->
<Exec Command="node --version" ContinueOnError="true">
<Output TaskParameter="ExitCode" PropertyName="ErrorCode" />
</Exec>
<Error Condition="'$(ErrorCode)' != '0'" Text="Node.js is required to build and run this project. To continue, please install Node.js from https://nodejs.org/, and then restart your command prompt or IDE." />
<Message Importance="high" Text="Restoring dependencies using 'npm'. This may take several minutes..." />
<Exec WorkingDirectory="$(SpaRoot)" Command="npm install" />
</Target>
<Target Name="PublishRunWebpack" AfterTargets="ComputeFilesToPublish">
<!-- As part of publishing, ensure the JS resources are freshly built in production mode -->
<Exec WorkingDirectory="$(SpaRoot)" Command="npm install" />
<Exec WorkingDirectory="$(SpaRoot)" Command="npm run build" />
<!-- Include the newly-built files in the publish output -->
<ItemGroup>
<DistFiles Include="$(SpaRoot)build\**" />
<ResolvedFileToPublish Include="#(DistFiles->'%(FullPath)')" Exclude="#(ResolvedFileToPublish)">
<RelativePath>%(DistFiles.Identity)</RelativePath>
<CopyToPublishDirectory>PreserveNewest</CopyToPublishDirectory>
</ResolvedFileToPublish>
</ItemGroup>
</Target>
</Project>
So, in summary, if I run msbuild .\LimeadeDocs.sln /t:publish from my command line, zip up the contents of \bin\Debug\netcoreapp2.1\publish and drop it on the web server, it works. However, when I deploy the contents of the Website artifact built in DevOps, I get the script error.
I also ran a diff between the bundle.js file produced locally and the one DevOps produces. There's massive amounts of differences, so I'm not quite sure what would account for that. Originally, it looked like different versions of packages were getting installed locally than on DevOps, but I've done everything I can think of to show that isn't the case. So, the bundling mechanism that takes all these packages and builds a giant bundle.js file must be running differently on DevOps as it does locally. However, it's all the same code. I'm pretty stuck as to where to go from here.
So, turns out the answer was to remove the package-lock.json file from the build so that the DevOps build agent has to generate the file itself. No idea what sort of environmental differences there are between my local build machine and the DevOps agent, but it seems the two files are incompatible and thus cannot be checked in to Git.
Hopefully this will help someone in the future who has run across this problem too.
react-native start command stuck on Loading dependency graph, done. Running Metro Bundler on port 8081.
Windows 8 :
node version : 8.11.3
npm version : 6.3.0
react-native: 0.56.0
package.json
{
"name": "TestApp",
"version": "0.0.1",
"private": true,
"scripts": {
"start": "node node_modules/react-native/local-cli/cli.js start",
"test": "jest"
},
"dependencies": {
"react": "16.4.1",
"react-native": "0.56.0"
},
"devDependencies": {
"babel-jest": "23.4.2",
"babel-preset-react-native": "5.0.2",
"jest": "23.5.0",
"react-test-renderer": "16.4.1"
},
"jest": {
"preset": "react-native"
}
}
It's supposed to get stuck there until a device successfully connects to it. The problem is probably that your device for some reason is unable to find your computer, in that case you should get an error message on the phone mentioning it can't connect to the development server. All those suggestions mentioned in that error message may help you solve the problem. Pay extra attention to the development server's host and port configuration. If you have configured the host and port a long time ago and it suddenly stopped to work, a likely cause could be that your computer has been assigned a new ip address, so maybe double check that you're using the correct IP address. Another problem may be that your computer isn't publicly visible on your network.
Try this.
Your device can't found localhost like Lenny Laughter said, and the solution to that is running adb -s <device name> reverse tcp:8081 tcp:8081.
This way, your device can see the port 8081 and connect to the Metro Bundler.
You need to start the app on your physical device or emulator.
So, I am developing React portlet for Liferay 7.0 CE. I have used blade command ( straight from the Liferay react template)
blade create -t npm-react-portlet -p fi.liferay.react.portlet -c ReactMain TestProject
Blade creates project as it should. After creation I changed to newly created project and ran
./gradlew build --stacktrace
First time build prints
npm WARN deprecated babel-preset-es2015#6.24.1: 🙌 Thanks for using Babel: we recommend using babel-preset-env now: please read babeljs.io/env to update!
And after that
Execution failed for task ':npmRunBuild'. > Process command '<pathToProject>/build/node/bin/node'' finished with non-zero exit value 1
-> Build failed.
When running again gradle build, build passes
When deploying to Liferay portal, browser console prints
ReferenceError: module is not defined[Learn More]
combo:1:1
Error: Load timeout for modules: TestProject#1.0.0
Stack trace:
require/</</s<#http://localhost:8080/o/frontend-js-web/everything.jsp?browserId=firefox&themeId=classic_WAR_classictheme&colorSchemeId=01&minifierType=js&minifierBundleId=javascript.everything.files&languageId=en_US&b=7004&t=1521557570840:288:322
I am using npm version 5.6.0 and Node version 9.8.0 . Blade CLI version is 2.3.1.201711201552
Operating system is MacOs High Sierra Version 10.13.3
I have tried with new portal and with Google Chrome and Mozilla firefox
It caused by the upgrade of liferay npm build tools.
It will be fixed after the new release of blade cli.
And you can also fix it by change your package.json file like the following:
{
"dependencies": {
"react": "15.6.2",
"react-dom": "15.6.2"
},
"devDependencies": {
"babel-cli": "6.26.0",
"babel-preset-es2015": "6.24.1",
"babel-preset-liferay-project": "1.6.1",
"babel-preset-react": "6.24.1",
"liferay-npm-bundler": "1.6.1",
"liferay-npm-bundler-preset-react": "1.6.1"
},
"main": "js/index.js",
"name": "npm-react-portlet70",
"scripts": {
"build": "babel --source-maps -d build/resources/main/META-INF/resources src/main/resources/META-INF/resources && liferay-npm-bundler"
},
"version": "1.0.0"
}
Hope that can fix your problem.