Note: this is a one-way operation. Once you eject, you can’t go back! … At this point you’re on your own.
Claims the CRA docs. However, I don't see why this is. If I am using a VCS, what is preventing me from rolling back the changes made by running npm run eject? This would imply there's something outside the project that affects it, which violates some vague notions about principles of modern web dev that I have in my head..
You can revert eject if you revert the changes in VCS.
eject will just copy configuration files to your working directory so that you have edit them the way you want.
Keep in mind that once you eject, there could be changes in structure in node_modules as scripts will be looking in different paths. Also, node_modules are generally not tracked in version management systems. So after you revert the eject, you might have to install dependencies with npm install or yarn
If that doesn't work, try removing node_modules directory and run npm install or yarn again.
Basically, everything that is tracked in version management systems can be reverted back.
In this case I think a picture begins to explain it. It appears to compile somewhat your app and package.json. Although my node_modules folder appears to get bigger, if I deleted it and type yarn it comes back but only 29 MB this time instead of the larger 175 MB you can see in the screenshot prior to this.
➜ aminosee copy git:(master) ✗ yarn
yarn install v1.13.0
[1/4] 🔍 Resolving packages...
[2/4] 🚚 Fetching packages...
[3/4] 🔗 Linking dependencies...
warning " > #typescript-eslint/eslint-plugin#1.6.0" has unmet peer dependency "typescript#*".
warning " > #typescript-eslint/parser#1.6.0" has unmet peer dependency "typescript#*".
warning "#typescript-eslint/eslint-plugin > #typescript-eslint/typescript-estree#1.6.0" has unmet peer dependency "typescript#*".
warning "#typescript-eslint/eslint-plugin > tsutils#3.10.0" has unmet peer dependency "typescript#>=2.8.0 || >= 3.2.0-dev || >= 3.3.0-dev || >= 3.4.0-dev".
[4/4] 🔨 Building fresh packages...
✨ Done in 68.43s.
Related
I created a new project with the vue cli.
This project is a Vue3 with Ant Design, Vue Router and Eslint.
However when I give the yarn command it shows me the following warnings.
yarn install v1.22.10
[1/4] Resolving packages...
[2/4] Fetching packages...
info fsevents#2.3.2: The platform "win32" is incompatible with this module.
info "fsevents#2.3.2" is an optional dependency and failed compatibility check. Excluding it from installation.
info fsevents#1.2.13: The platform "win32" is incompatible with this module.
info "fsevents#1.2.13" is an optional dependency and failed compatibility check. Excluding it from installation.
[3/4] Linking dependencies...
warning "#vue/eslint-config-airbnb > eslint-import-resolver-webpack#0.13.0" has unmet peer dependency "webpack#>=1.11.0".
warning " > less-loader#7.3.0" has unmet peer dependency "webpack#^4.0.0 || ^5.0.0".
[4/4] Building fresh packages...
Done in 26.91s.
The webpack I noticed is already installed directly on vue 3. How do I resolve these warnings?
for fsevents it seems that it's a MacOS-only library so that might explain why you got the first error.
for peer dependencies and webpack if you are using Yarn it seems that you have to do yarn add webpack --peer or as #kaumadie said in a comment you can also add it directly on the package.json file of your project
With npm, you can do npm i directly in the project's folder and it should resolve all peer dependencies automatically
Hope it helped you, and have a good day !
I pretty much always end up adding my NPM modules peer dependencies to dev dependencies as well because I need the peer dependencies installed so I can run automated tests before building the package. This creates the problem that I might accidentally use different version number for peer and dev. I find it odd that npm and yarn do not install the peer dependencies automatically when I run npm install or the yarn command. In some cases I have found that yarn even tries to prevent me from adding the same dependency as both peer and dev dependency. I think I'm doing something wrong but I haven't been able to figure out the intended workflow. Can someone explain to me how this is supposed to work?
I tried the latest vue-cli 3 tool... full install
project setup is done correctly, but as soon as I add a new dependency, I get a list of warnings, unmet dependencies ... is it due to yarn ( I did not test npm..) or not. Anyway to solve them?
$ yarn add vue-i18n
yarn add v1.9.4
[1/4] 🔍 Resolving packages...
[2/4] 🚚 Fetching packages...
[3/4] 🔗 Linking dependencies...
warning "#vue/cli-plugin-babel > babel-loader#8.0.0-beta.4" has unmet peer dependency "webpack#>=2".
warning "#vue/cli-plugin-eslint > eslint-loader#2.1.0" has unmet peer dependency "webpack#>=2.0.0 <5.0.0".
warning "#vue/cli-plugin-pwa > workbox-webpack-plugin#3.4.1" has unmet peer dependency "webpack#^2.0.0 || ^3.0.0 || ^4.0.0".
warning "#vue/eslint-config-prettier > eslint-config-prettier#2.10.0" has unmet peer dependency "eslint#>=3.14.1".
warning " > babel-core#7.0.0-bridge.0" has unmet peer dependency "#babel/core#^7.0.0-0".
warning " > sass-loader#7.1.0" has unmet peer dependency "webpack#^3.0.0 || ^4.0.0".
[4/4] 📃 Building fresh packages...
success Saved lockfile.
success Saved 1 new dependency.
info Direct dependencies
└─ vue-i18n#8.0.0
info All dependencies
└─ vue-i18n#8.0.0
✨ Done in 34.88s.
tl;dr: Probably not a problem except for webpack (but still probably not a problem). Since webpack is a peer dependency for multiple dependencies, non-deterministic behavior could arise due to different version constraints being listed in different dependencies.
What's Going On
Yarn presents these warnings to prevent different dependencies requiring different versions of a third sub-dependency, which may cause non-deterministic behavior. For instance here, babel-loader, eslint-loader, workbox-webpack-plugin, and sass-loader all have slightly different version constraints on webpack, which means without a yarn.lock file the version constraints are not exactly predictable. To resolve this, you could add webpack as an explicit dependency for your project, or you could yarn upgrade webpack#x.x.x to the version you desire then rely on your yarn.lock to specify this version.
The Solution
In your specific case, the only peer dependency you should be worried about is webpack because all the other ones are only required by a single dependency. However, its likely that no problems will arise if you were to just do nothing about these warnings.
Ideally, this should have been resolved by Vue in vue create process by adding webpack to the package.json, but since I am able to reproduce this error on my end I am guessing that they have not gotten around to it. I would encourage you to create an issue if one has hasn't already been made for this.
More info on Peer Dependencies
A project maintainer can specify peer dependencies in the project's package.json when they believe dependency conflicts could arise when using the package. For instance, if you visit the package.json for #vue/cli-plugin-babel then you will see webpack#>=2 listed in a peerDependencies section. Whoever wrote this Vue plugin likely added webpack as a peer dependency because they were aware how popular webpack is and wanted to warn the user that this plugin uses webpack so as to help them deal with potential conflicts.
While written with npm instead of yarn in mind, I found this article presents some useful advice for working with peer dependencies and peer dependency warnings.
I am using react native init to initialize my project, and I'm getting some warnings, which I'm sure will come to bite me in the back later on If I don't deal with them now. In bold are the concerning messages. I'm not entirely sure what to do about them, can anyone inform me how to fix this/if I'm doing something wrong that I am receiving these messages/warnings? A beginner friendly/light on the terminology answer would be appreciated, as I'm new to react native
yarn add v0.27.5
info No lockfile found.
[1/4] Resolving packages...
warning react-native > connect#2.30.2: connect 2.x series is deprecated
[2/4] Fetching packages...
[3/4] Linking dependencies...
warning "react-native#0.47.2" has unmet peer dependency "react#16.0.0-alpha.12".
This react-native init command is also taking very long (~ 5 minutes per use). Are the above warnings causing the long startup time, or something else?
info is just some infomation, not a problem
and for the two warning:
deprecated connect
about the deprecated connect version,I came up with too, it's because react-native depends on connect, and react-native's latest version is 0.49.3, it use connect#2.30.2,a little bit deprecated, and there's someone made a pr about this problem, Github:pr
,but has not been merged because of some test coverage, so now just ignore this warning;
unmet peer dependency
it's related to some deprecated package.
All I've found to solve these warnings is to:
1) Update all react-native packages
npm install react-native#latest --save
This can often solve problems with outdated/deprecated npm packages
2) Install react#16.0.0-alpha.12
npm install react#16.0.0-alpha.12
3) Update connect#2.30.2
npm update connect#2.30.2
Again, warnings #1 and #2 are pretty common
The "No lockfile found" just means that the installation hadn't been run before; the lockfile keeps track of exact installed package versions.
Searching for the other two are how I got here so I'm not going to be any help on those (yet). ;-).
I'm getting npm ERR! invalid errors when I try npm ls or npm install, and it seems like npm is incorrectly thinking peers have incompatible versions. A good example (I get several of these at a time):
npm WARN unmet dependency /MYLOCALPROJECTDIRECTORY/node_modules/grunt-contrib-imagemin/node_modules/imagemin/node_modules/imagemin-gifsicle requires image-type#'^0.1.1' but will load
npm WARN unmet dependency /MYLOCALPROJECTDIRECTORY/node_modules/grunt-contrib-imagemin/node_modules/imagemin/node_modules/image-type,
npm WARN unmet dependency which is version 0.1.4
According to the rules of semver, the caret "^" operator should match a requirement of ^0.1.1 with an actual dependency of version 0.1.4 just fine.
I've installed Node v0.10.30 with npm v1.4.23 using Homebrew (both the latest stables), running OS X Mountain Lion. I'd appreciate tips on finding how to reliably reproduce this - last time I totally uninstalled/reinstalled Node and npm, same local npm modules and everything, and could not find the error again. Came back to work the next day, tried to install some grunt plugin, and ran into all these errors again.
If you happen to reproduce it, I bet you can solve it by removing the node_modules folder, cleaning the cache and reinstalling:
rm -rf ./node_modules
npm cache clean
npm install
I know this is not an actual answer, but I guess it's better than uninstalling/reinstalling node/npm.