I have something like this:
WARNING in C:/Data/.../letsTest.jsx
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:\Data\...\node_modules\babel-loader\lib\index.js?presets[]=es2015&presets[]=react&presets[]=stage-0&presets[]=stage-2!C:\Data\...\letsTest.jsx
Used by 4 module(s), i. e.
multi C:/Data/Doc/13/13080801/LetsTest/letsTest.jsx
* C:\Data\...\node_modules\babel-loader\lib\index.js?presets[]=es2015&presets[]=react&presets[]=stage-0&presets[]=stage-2!c:\Data\...\letsTest.jsx
Used by 1 module(s), i. e.
C:\Data\...\node_modules\babel-loader\lib\index.js?presets[]=es2015&presets[]=react&presets[]=stage-0&presets[]=stage-2!C:\Data\...\r1HeadLearning.js
What is the issue?
Eventually, I found the answer.
It was a Windows issue. It was necessary to change the absolute path in C:\Data...\r1HeadLearning.js from
c:\Data\...\letsTest.jsx
to
C:\Data\...\letsTest.jsx
Delete the node_modules folder and run npm install
That fixed my problem
I just fixed the same warnings on my system, where I'm coding a Create-React-App on Windows 10. Since the Windows file system is not case sensitive, this did not prevent me from continuing to work, but it was ugly to look at on my terminal output. In investigating, none of the available answers helped me. But in a few days of ruminating on the problem I thought of a possible cause. In the recent past I had used npm a couple of times to install modules instead of my usual yarn. Since the warnings were all pointing to node-modules, I decided that could have been a mistake. So here is what I did:
First I merged my develop branch into my master branch, getting everything into one branch.
Next I deleted the entire node_modules folder.
Then I ran yarn install to load all the package.json modules.
Finally I did a yarn start, and the warnings were gone.
Maybe this will help you.
From Contributing.md in create-react-app:
The scripts in tasks folder and other scripts in package.json will not work in Windows out of the box. However, using Bash on windows makes it easier to use those scripts without any workarounds.
so, the easier way is to just install Bash and npm install there. the steps are:
Install Bash on Ubuntu on Windows
A good step by step guide can be found
here
Install Node.js and yarn
Even if you have node and yarn installed on your windows, it would not
be accessible from the bash shell. You would have to install it again.
Installing via
nvm is
recommended.
Line endings
By default git would use CRLF line endings which would cause the
scripts to fail. You can change it for this repo only by setting
autocrlf to false by running git config core.autocrlf false. You
can also enable it for all your repos by using the --global flag if
you wish to do so.
Related
I am using a template, Vue cli3 application and it stopped working and I don't recall why. The error I am receiving is when I try to start the application I get this error.
yarn run serve
yarn run v1.16.0
error An unexpected error occurred: "The \"path\" argument must be of type string. Received type object".
info If you think this is a bug, please open a bug report with the information provided in "C:\\node\\TradeTriggers\\yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
I can delete the node_modules and package.json.lock
I cannot do anything with yarn. No yarn install, yarn run serve, nothing and npm doesn't seem to want to run the application. I'm sorry there are a lot of tools to know in the JS world!
The machine is a windows10 machine and I cannot find yarn in my env variables, so the issue may lie there. I even tried installing the Yarn MSI but my version is still the one I installed through npm a while ago, still nothing.
I had problem that was caused by yarn looking at first the global settings file, ie global registry. It might be similar. On Windows, first check your yarn config path:
yarn config bin
Windows shows the path. Then in that folder, check whether you have a "rc" file, ie that is yarn configuration.
Try move this file out of the folder, for test. Have it as a copy somewhere else, where you can restore it if this does not help.
Then, once file is out, run your yarn commands again like you used to.
Sideline: on Linux, I had to remove a leftover buggy .yarnrc file in
/usr/local/share/.yarnrc
to get similar things working again. It was not a Vue app, but similar kind of error.
This error can occur when you are using Yarn Workspaces and have incompatible directories in the packages/ directory.
In my scenario, I used git subtrees to pull another repo into my project's packages/ directory. This directory had a package.json file, but it did not have compatible values for the fields required by Yarn Workspaces.
Moving the problematic package out of packages/ should fix this issue.
I have been using npm for a personal project and just recently stumbled across yarn. Would there be any harm or "intended side effects" to switching to yarn's package manager in the same project where I had been using npm?
Although a few commenters here say its ok to mix both yarn and npm on the same project, after using yarn and npm and then yarn again, this is what yarn has to say about it:
warning package-lock.json found. Your project contains lock files generated by tools
other than Yarn. It is advised not to mix package managers in order to avoid resolution
inconsistencies caused by unsynchronized lock files. To clear this warning, remove
package-lock.json.
Since to me it is not any harm to using both them into one project.
I use npm and yarn (50/50) in dev environment.
But on ci/di i use only yarn because it is faster, and i reduce build minutes thanks yarn.
Also they both create different .lock file names.
Nobody told about the lock files.
Imagine you use yarn on dev environment, and yarn on your build/production servers. When you install a package using yarn, and your project works on your computer, you probably would want to keep it working on a production environment (your server).
That being sad, you would commit you yarn.lock file, that "saves" the exact versions of each package you have, when the project ran on your computer.
On your buid/production server you should call yarn install, but asking to keep all the same versions with --frozen-lockfile parameter. Some even say "yarn install --frozen-lockfile should be the default behavior", and I agree.
Then... another dev jump in the project you are working and install a package using npm (other than yarn). That new package will not be included in your yarn.lock file, but, a new package-json.lock file would be created, telling the exact packages versions it is using.
When that commit arrives on your build/production server, it will crash, fail, because that new package doesn't exist on yarn.lock file. Someone would need to pull that changes, call a yarn to install the dependences and update the lock file with the new package dependences, and push it again to the repo.
A quick point about using the lock file or not. If you call a 'yarn install' on your build/production server some weeks after the last install on your machine, the server would have many other new versions than your last "stable" version. It already happened to me many times.
I published recently the package-locks-checks, which help ensure you have not just one lock file but also locked each package version on your project.
There will be a point that one or both will no longer work and your project will be stuck at only using the existing lock file. Meaning, the issue probably will involve installation fails if you opt to reinstall without a lock file. And that also means failure to create a new lock file, so you are stuck with the existing one that you are trying to get rid off in the first place. We are actually encountering this issue in one of our projects. Because it is so big, no one tries to fix the issue and just rely on the existing lock file.
So, even if we say it's a rare case that it won't cause harm. Mixing npm and yarn should be avoided.
Here https://classic.yarnpkg.com/en/docs/migrating-from-npm/ we may find a confirmation that Yarn's resolution algorithm is compatible with NPM resolution algorithm.
Inside a npm project (with package.json) if you run yarn it will read your node_modules folder (using the resolution algorithm) and create a yarn.lock file with your project's locked dependency tree.
Based on that I assume that they are compatible inside the same project.
Update 30/04/2021
My original reply refers to yarn 1 (classic), although I've just created a React app with create-react-app tool and it creates the project's repository with package.json + yarn.lock by default. Again, another demonstration that it's fine (even with the warning mentioned by Dave Pile).
At the end of the day this is a matter of putting both together to work and checking yourself...
Plus you get a warning from yarn as Dave Pile said because we have to push *-lock.json files changes you have to consider using npm version >= 7 to make sure whenever you install packages by npm it will update your yarn-lock.json file too.
Because whenever you install the packages either by npm or yarn depends on what you have chosen for updating a dependency in the package.json (Using tilde ( ~ ) which gives you bug fix releases and caret ( ^ ) gives you backward-compatible new functionality) it will update you.lock file and since you have to push it might happen that you have different version of lock files.
Yarn creates a yarn.lock file after you perform a yarn install.
Should this be committed to the repository or ignored? What is it for?
Yes, you should check it in, see Migrating from npm
What is it for?
The npm client installs dependencies into the node_modules directory non-deterministically. This means that based on the order dependencies are installed, the structure of a node_modules directory could be different from one person to another. These differences can cause works on my machine bugs that take a long time to hunt down.
Yarn resolves these issues around versioning and non-determinism by using lock files and an install algorithm that is deterministic and reliable. These lock files lock the installed dependencies to a specific version and ensure that every install results in the exact same file structure in node_modules across all machines.
Depends on what your project is:
Is your project an application? Then: Yes
Is your project a library? If so: No
A more elaborate description of this can be found in this GitHub issue where one of the creators of Yarn eg. says:
The package.json describes the intended versions desired by the original author, while yarn.lock describes the last-known-good configuration for a given application.
Only the yarn.lock-file of the top level project will be used. So unless ones project will be used standalone and not be installed into another project, then there's no use in committing any yarn.lock-file – instead it will always be up to the package.json-file to convey what versions of dependencies the project expects then.
I see these are two separate questions in one. Let me answer both.
Should you commit the file into repo?
Yes. As mentioned in ckuijjer's answer it is recommended in Migration Guide to include this file into repo. Read on to understand why you need to do it.
What is yarn.lock?
It is a file that stores the exact dependency versions for your project together with checksums for each package. This is yarn's way to provide consistency for your dependencies.
To understand why this file is needed you first need to understand what was the problem behind original NPM's package.json. When you install the package, NPM will store the range of allowed revisions of a dependency instead of a specific revision (semver). NPM will try to fetch update the dependency latest version of dependency within the specified range (i.e. non-breaking patch updates). There are two problems with this approach.
Dependency authors might release patch version updates while in fact introducing a breaking change that will affect your project.
Two developers running npm install at different times may get the different set of dependencies. Which may cause a bug to be not reproducible on two exactly same environments. This will might cause build stability issues for CI servers for example.
Yarn on the other hand takes the route of maximum predictability. It creates yarn.lock file to save the exact dependency versions. Having that file in place yarn will use versions stored in yarn.lock instead of resolving versions from package.json. This strategy guarantees that none of the issues described above happen.
yarn.lock is similar to npm-shrinkwrap.json that can be created by npm shrinkwrap command. Check this answer explaining the differences between these two files.
You should:
add it to the repository and commit it
use yarn install --frozen-lockfile and NOT yarn install as a default both locally and on CI build servers.
(I opened a ticket on yarn's issue tracker to make a case to make frozen-lockfile default behavior, see #4147).
Beware to NOT set the frozen-lockfile flag in the .yarnrc file as that would prevent you from being able to sync the package.json and yarn.lock file. See the related yarn issue on github
yarn install may mutate your yarn.lock unexpectedly, making yarn claims of repeatable builds null and void. You should only use yarn install to initialize a yarn.lock and to update it.
Also, esp. in larger teams, you may have a lot of noise around changes in the yarn lock only because a developer was setting up their local project.
For further information, read upon my answer about npm's package-lock.json as that applies here as well.
This was also recently made clear in the docs for yarn install:
yarn install
Install all the dependencies listed within package.json
in the local node_modules folder.
The yarn.lock file is utilized as follows:
If yarn.lock is present and is enough to satisfy all the dependencies
listed in package.json, the exact versions recorded in yarn.lock are
installed, and yarn.lock will be unchanged. Yarn will not check for
newer versions.
If yarn.lock is absent, or is not enough to satisfy
all the dependencies listed in package.json (for example, if you
manually add a dependency to package.json), Yarn looks for the newest
versions available that satisfy the constraints in package.json. The
results are written to yarn.lock.
If you want to ensure yarn.lock is not updated, use --frozen-lockfile.
From My experience I would say yes we should commit yarn.lock file. It will ensure that, when other people use your project they will get the same dependencies as your project expected.
From the Doc
When you run either yarn or yarn add , Yarn will generate a yarn.lock file within the root directory of your package. You don’t need to read or understand this file - just check it into source control. When other people start using Yarn instead of npm, the yarn.lock file will ensure that they get precisely the same dependencies as you have.
One argue could be, that we can achieve it by replacing ^ with --. Yes we can, but in general, we have seen that majority of npm packages comes with ^ notation, and we have to change notation manually for ensuring static dependency version.But if you use yarn.lock it will programatically ensure your correct version.
Also as Eric Elliott said here
Don’t .gitignore yarn.lock. It is there to ensure deterministic dependency resolution to avoid “works on my machine” bugs.
Not to play the devil's advocate, but I have slowly (over the years) come around to the idea that you should NOT commit the lock files.
I know every bit of documentation they have says that you should. But what good can it possibly do?! And the downsides far outweigh the benefits, in my opinion.
Basically, I have spent countless hours debugging issues that have eventually been solved by deleting lock files. For example, the lock files can contain information about which package registry to use, and in an enterprise environment where different users access different registries, it's a recipe for disaster.
Additionally, the lock files can really mess up your dependency tree. Because yarn and npm create a complex tree and keep external modules of different versions in different places (e.g. in the node_modules folder within a module in the top node_modules folder of your app), if you update dependencies frequently, it can create a real mess. Again, I have spent tons of time trying to figure out what an old version of a module was still being used in a dependency wherein the module version had been updated, only to find that deleting the lock file and the node_modules folder solved all the hard-to-diagnose problems.
I even have shell aliases now that delete the lock files (and sometimes node_modules folders as well!) before running yarn or npm.
Just the other side of the coin, I guess, but blindly following this dogma can cost you........
I'd guess yes, since Yarn versions its own yarn.lock file:
https://github.com/yarnpkg/yarn
It's used for deterministic package dependency resolution.
Yes! yarn.lock must be checked in so any developer who installs the dependencies get the exact same output! With npm [that was available in Oct 2016], for instance, you can have a patch version (say 1.2.0) installed locally while a new developer running a fresh install might get a different version (1.2.1).
Yes, You should commit it. For more about yarn.lock file, refer the official docs here
OS: Ubuntu 12.04
Go version reporting: 1.1.1
Action:
I have configured the .profile to contain the following lines:
export GOPATH="$HOME/workspace"
export PATH=$PATH:$GOPATH/bin
I have ensured that they are set in the go configuration by running "go env". However when I try to run the command, the screen reports as shown in the image below:
Possible constraining issues:
1) The box originally had Go v1.0 on it and I upgraded it to go version1.1.1, not sure that should mean anything...but if there is some twin configuration madness at work that may explain the fact it's not working despite the path being set.
2) I had the export commands in the .profile file but I see some threads indicate to put it in .bashrc, trying in either still gives the same problem.
Do I need to uninstall go 1.0 ? I just assumed version 1.1.1 would over ride it but that could be wrong. Ideally I wanted to uninstall go entirely and then install version 1.1.2 but I couldn't find anything at golang.org on uninstalling assuming that does solve the problem.
Thanks in advance for any assistance.
As the commenter above stated, you should not use sudo with go get. When you do, you have the root user's environment (which doesn't have your GOPATH) and any files or directories it creates won't be editable by your user. In the past, the go get command would not warn about not having a $GOPATH and so it was easier to get tripped up by this.
To fix your permissions, run the following command to change ownership back to your user:
sudo chown -R "$USER:" "$GOPATH"
You should only ever need to run a plain go get because you can (and should) set your $GOPATH to be a directory you can control. Be sure to read the How To Write Go Code and in particular its discusson on GOPATH.
I know this question may have appeared few times here and in the internet. But still I feel it is not clear for somebody who wanted to enter into the world of frameworks. I have followed these links Rob Allens Tutorial, ZF Quick Tutorial.
But some how I feel it is not quite clear with the installation part. I have a windows system basically Vista with the newest version of XAMPP installed. I have downloaded the latest version of ZFSkeletonApplication from this link ZFSkeletonApp, extracted the skeleton contents, renamed the folder to zendframework and moved it to xampp folder i.e now ZF skeleton is in c:\xampp\zendframework.
So until here everything seems clear and easy, from here I am some how lost with the configurations. Can some one elaborate the things from here how to install the Zf and make it work, like changes in the include paths, .htaccess files and so on. Please do remember that I have windows with XAMPP on it. If some one can guide me exactly for this set up, it would be helpful.
P.S. It would be good if one can provide info about the changes which I need to make with examples consisting of paths, so that I am not lost, for example like you can find .htaccess file here(ex pathname), changes in .htaccess file should be so and so.
Thanks
For future references, i also made a big post on how to install ZF2 on a windows xampp environment right here Install ZF2 on Windows Xampp
OK, i have done this on multiple systems now. For a home system the following steps work quite well:
Download msysGit and install it to any directory
Run the git-cmd.bat from the msysGit-Folder
Move into the directory you want i.e. C:\xampp\htdocs\ (this is done via cd dirname or cd .. to go up a level, change partition with D: and hit enter)
Run the following command. The <OptionalFolderName> would be the name of a Sub-Directory of htdocs, if you skip this, the folder will get named ZendSkeletonApplication
git clone git://github.com/zendframework/ZendSkeletonApplication.git <OptionalFolderName>
Possible Trouble Scenario (fatal:unable to connect to github.com)
Once again at workplaces, pretty often the default port (9418) for the git-protocol is blocked. If this is the case for you, then you should try one of the following Commands
git clone https://github.com/zendframework/ZendSkeletonApplication.git <OptionalFolderName>
git clone git#github.com:zendframework/ZendSkeletonApplication.git <OptionalFolderName>
Now you are not done yet. The skeleton Application is installed, but the framework is still missing, here some people might run into the first problems, but this actually is quite easy.
We're still at the command line interface
cd <OptionalFolderName> or cd ZendSkeletonApplication depending on what you did earlier
php composer.phar self-update
php composer.phar install (this might take a while)
So, this is the part where lots of things can happen. I have two scenarios happened to me:
Scenario #1 No directory write permissions
This is easily handled by running the command line interface with administrator privileges
Scenario #2 Working behind a router (i.e. at work)
Personally i didn't have to do much to get this working, but the line might change depending on your proxy. Personally i did the following at the command line interface
SET HTTP_PROXY=http://proxy.domain.tld:8080 you might also be good with
SET HTTP_PROXY=proxy.domain.tld:8080 don't ask me why, but i needed the http://
With all those done, you should have an almost running ZendSkeletonApplication. The other part is how to set up your virtual host, but i won't go into detail on this, as that's even ZF1 Stuff and everyone should be familiar with that by now, if not, there's good resources to learn out there.
I hope i could be of help to you.
Setbacks have to install in Windows, but I ended up finding a solution. From ZF2 to install on windows via git, for this is the only use that simulates msysGit git linux on windows, for it is only access the tutorial: http://zf2.com.br/tutoriais/post/instalando-o-git-no-windows-para-fazer-a-instalacao-do-zf2-somente-no-comando-do-windows-via-composer
Since I had lot dependency extension problems (mostly .dll files) with old version of XAMPP, so first thing I did was made sure I uninstall all previous versions of PHP already present on my system as well as old XAMPP. Then installed latest XAMPP v3.2.2 (using latest XAMPP 3.2.2-32-bit on Win-7-64-bit). Then followed installation steps in XAMPP Documentation under title Start a New Zend Framework 2 Project.
I had issues while installing composer also with old-XAMPP, but somehow those errors didn't appear during composer installation this time. And, I successfully installed ZEND till I typed http://localhost:8081/myapp/ (I renamed my ZendSkeletonAppliction folder as myapp as per documentation) into my browser to access the same and met the error which said:
Fatal error: Uncaught RuntimeException: Unable to load ZF2. Run php composer.phar install or define a ZF2_PATH environment variable. in C:\xampp\apps\myapp\htdocs\init_autoloader.php:51
Stack trace:
#0 C:\xampp\apps\myapp\htdocs\public\index.php(18): require()
#1 {main} thrown in C:\xampp\apps\myapp\htdocs\init_autoloader.php on line 51
Composer.phar was not even present the first time I downloaded ZendSkeletonApplication‐master.zip from Github (there was only composer.json and composer.lock files present). Anyhow I didn't need them since I followed XAMPP Doc which doesn't call composer.phar in command line:
composer create‐project ‐s dev zendframework/skeleton‐application path/to/install
I am not that tech-savvy to know how to 'define a ZF2_PATH environment variable' correctly, so I wasted time looking for solution online, couldn't find any (which is when I stumbled on this forum which also turned out not to have a solution for my query). In the end, in a fit of depression and anxiety, serendipity happened. All I did was as per XAMPP's ZEND documentation I right-clicked inside C:\xampp\apps\myapp\htdocs folder and clicked 'Composer Install' which reinstalled the Zend files from cache. Then refreshed http://localhost:8081/myapp/ and the Zend intro page appeared.
I just did it like that:
D:\web_dev\zendapp>C:\PHP\php.exe composer.phar self-update
it worked perfectly