My react native project build fails somehow because of this error:
Execution failed for task ':app:mergeDebugNativeLibs'.
> A failure occurred while executing com.android.build.gradle.internal.tasks.MergeNativeLibsTask$MergeNativeLibsTaskWorkAction
> 2 files found with path 'lib/arm64-v8a/libfbjni.so' from inputs:
- C:\Users\Antonio\.gradle\caches\transforms-3\7cca348744e25f57fc2d9f871aa73c9a\transformed\jetified-react-native-0.71.0-rc.0-debug\jni\arm64-v8a\libfbjni.so
- C:\Users\Antonio\.gradle\caches\transforms-3\08b0f5c7017bf081f79b63ea5b053dc0\transformed\jetified-fbjni-0.3.0\jni\arm64-v8a\libfbjni.so
If you are using jniLibs and CMake IMPORTED targets, see
https://developer.android.com/r/tools/jniLibs-vs-imported-targets
Anybody got a clue what could cause the build to fail? I haven't edited any build file and/or removed/installed/upgraded new packages thanks
For me this worked (after reading Tony's link), my version of react was 0.66.0
Changed this file android\app\build.gradle
implementation "com.facebook.react:react-native:+" // From node_modules
to
implementation "com.facebook.react:react-native:0.66.0!!" // From node_modules
Short answer:
in your android/app/build.gradle
change
implementation 'com.facebook.react:react-native:+'
to ---> (replace 0.67.2 with your current react native version)
implementation 'com.facebook.react:react-native:0.67.2!!'
Long answer:
This is happening because all the templates reference the React Native dependency by range, like implementation 'com.facebook.react:react-native:+'. Usually this dependency gets resolved from the local Maven repo in ./node_modules/react-native/android but since it has been published to Maven Central it's now grabbing the very latest RC.
You can resolve this problem by forcing the React Native dependency to the version you expect with something like this implementation 'com.facebook.react:react-native:0.67.2!!' in your app's Gradle file. The !! is shorthand for restricting Gradle from upgrading if your project or its transitive dependencies depend on a newer version.
work for me, if your react native application version >= 0.63 you can update the patch version which should fix your problem.
link: https://github.com/facebook/react-native/issues/35210#:~:text=We%20have%20prepared%20releases%20for%20all%20the%20main%20versions%20of%20react%2Dnative%20with%20an%20hotfix%3A
if not just go to android/build.gradle and then in the allprojects object add the following code with the current version of react native in package.json
configurations.all {
resolutionStrategy {
force 'com.facebook.react:react-native:CURRENT_VERSION_OF_REACT_NATIVE'
}
}
Here's a workaround to fix this problem if you are not using latest version of react-native.
https://github.com/facebook/react-native/issues/35210
Go to android folder -> build.gradle file -> inside allprojects object and add following code. Add react native version from node_modules -> react-native -> package.json // "version": "0.68.2".
configurations.all {
resolutionStrategy {
force 'com.facebook.react:react-native:0.68.2'
}
}
See fb/rn#35204
This is the Official recommended fix!
Found through this issue: https://github.com/facebook/react-native/issues/35210.
Copied from this PR here
For my RN 0.66.0 project I only had to add theses lines:
allprojects {
repositories {
exclusiveContent {
// Official recommended fix for Android build problem with React Native versions below 0.71
// https://github.com/facebook/react-native/issues/35210
// TODO: remove this exclusiveContent section when we upgrade to React Native 0.71 (or above)
// copied from https://github.com/Scottish-Tech-Army/Volunteer-app/pull/101/commits/40a30310ee46194efbaf1c07aef8a0df70231eeb
filter {
includeGroup "com.facebook.react"
}
forRepository {
maven {
url "$rootDir/../node_modules/react-native/android"
}
}
}
}
}
I had the same issue. There is a new patch for react-native now so update it in your package.json.
Mine is
"react-native": "^0.70.3"
and I changed it to
"react-native": "^0.70.5"
which worked for me
The answer lies here depending on the version of your react native. Patches are available for RN version 0.63 and up
https://github.com/facebook/react-native/issues/35210
Tips:
Don't just update react-native package, do an npm install
Clean gradle before running the app
Only add the code below IF your react native version is < 0.63
def REACT_NATIVE_VERSION = new File(['node', '--print',"JSON.parse(require('fs').readFileSync(require.resolve('react-native/package.json'), 'utf-8')).version"].execute(null, rootDir).text.trim())
allprojects {
configurations.all {
resolutionStrategy {
// Remove this override in 0.65+, as a proper fix is included in react-native itself.
force "com.facebook.react:react-native:" + REACT_NATIVE_VERSION
}
}
}
I am new to pnpm workspaces and am trying to resolve the following issue.
My demo project:
root
packages
common-ui
main-lib
common-ui is a Vite based package containing some Vue components that can be reused by other packages, in my example it's being used by main-lib.
"dependencies": {
"ui-common": "workspace:*"
},
common-ui is referencing an index.ts inside its package.json
"main": "index.ts",
index.ts is exporting my Vue components:
...
export { default as Heading } from './components/Heading/Heading.vue';
...
Now I am able to import those components inside main-lib:
import { Heading } from 'common-ui'
This all works fine but I would also like to be able to publish my library to the npm registry. As common-ui is using the Vite, it's possible to build in library mode: https://vitejs.dev/guide/build.html#library-mode. My package inside common-ui will need to change to:
{
"name": "common-ui",
"files": ["dist"],
"main": "./dist/common-ui.umd.js",
"module": "./dist/common-ui.es.js",
"exports": {
".": {
"import": "./dist/common-ui.es.js",
"require": "./dist/common-ui.umd.js"
}
}
}
main is not referencing index.ts anymore but a dist folder that only gets updated when the vite command is ran. Is there a way for me to support both publishing/versioning and referencing the actual source code from inside main-lib?
I've taken a quick look at Rush.js but I am not sure if provides a solution and I want to be sure before I continue on that path.
I have one react-native app in which I am using "json-schema-rules" library. Now I have also created one library which is getting used in my react-native app like this "file:../custom_library" in package.json.
Now to resolve the version conflict, I decided to use "json-schema-rules" as a peer dependency in my custom library. So, the package.json is like this
Package.json of my react-native app:
{
"dependencies": {
"json-rules-engine": "^2.3.0",
"custom_library": "file:../custom_library"
}
}
package.json of my custom_library:{
"peerDependencies": {
"json-schema-rules": "^2.3.0"
}
}
Now the problem is, whenever I am using metro bundler, I get an error
error: bundling failed: Error: Unable to resolve module json-rules-engine
json-rules-engine could not be found within the project.
This is the case when I am using it in peerDependencies, I do not get any error if I use this library in dependencies.
Please help.
You can try to add an alias for the module in your project's babel config.
This means that when your custom packages tries to import "json-rules-engine" it will get served the version from the main app.
First install 'babel-plugin-module-resolver' then configure the alias in "module-resolver"
babel.config.js
const config = {
presets: ["module:metro-react-native-babel-preset"],
plugins: [
[
"module-resolver",
{
root: ["./src"],
extensions: [".js", ".jsx", ".ios.js", ".android.js"],
alias: {
"json-rules-engine": require.resolve("json-rules-engine")
}
}
]
]
};
module.exports = config;
When I install a module, a list of phantomChildren appears in the package.json file. What are phantomChildren?
I didn't find official documentation for npm package phantomChildren. But encountered some other explanation: https://rushjs.io/pages/advanced/phantom_deps/. It is about rast, but explains behavior of npm dependencies pretty well.
For example library A might import definitions from libraries B and C, but then B and C can both import from D, which creates a “diamond dependency” between these four packages.
A “phantom dependency” occurs when a project uses a package that is
not defined in its package.json file.
Some live example:
my-library/package.json
{
"name": "my-library",
"version": "1.0.0",
"main": "lib/index.js",
"dependencies": {
"minimatch": "^3.0.4"
},
"devDependencies": {
"rimraf": "^2.6.2"
}
}
my-library/lib/index.js
var minimatch = require("minimatch")
var expand = require("brace-expansion"); // ???
var glob = require("glob") // ???
Wait a sec – two of these libraries are not declared as dependencies
in the package.json file. How is this working at all!? It turns out
that brace-expansion is a dependency of minimatch, and glob is a
dependency of rimraf. During installation, NPM has flattened their
folders to be under my-library/node_modules. The NodeJS require()
function finds them there because it probes for folders without
considering the package.json files at all.
To summarize: if package uses dependencies of it's own dependencies, it can be treated as phantomChildren. Package doesn't have such dependencies directly but uses it from other places.
I would like to use the grunt-contrib-jasmine NPM package. It has various dependencies. Part of the dependency graph looks like this:
─┬ grunt-contrib-jasmine#0.4.1
│ ├─┬ grunt-lib-phantomjs#0.2.0
│ │ ├─┬ phantomjs#1.8.2-2
Unfortunately, there's a bug in this version phantomjs which prevents it from installing correctly on Mac OS X. This is fixed in the latest version.
How can I get grunt-lib-phantomjs to use a newer version of phantomjs?
Some additional context:
grunt-contrib-jasmine explicitly requires version "~0.2.0" of grunt-lib-phantomjs, which explicitly requires version "~1.8.1" of phantomjs.
Adding phantomjs to my package's dependencies first has no effect; both versions are installed and grunt-contrib-jasmine still uses the older versions (see: When installing a package with NPM, can you tell it to use a different version of one of its dependencies?).
You can use npm shrinkwrap functionality, in order to override any dependency or sub-dependency.
I've just done this in a grunt project of ours. We needed a newer version of connect, since 2.7.3. was causing trouble for us. So I created a file named npm-shrinkwrap.json:
{
"dependencies": {
"grunt-contrib-connect": {
"version": "0.3.0",
"from": "grunt-contrib-connect#0.3.0",
"dependencies": {
"connect": {
"version": "2.8.1",
"from": "connect#~2.7.3"
}
}
}
}
}
npm should automatically pick it up while doing the install for the project.
(See: https://nodejs.org/en/blog/npm/managing-node-js-dependencies-with-shrinkwrap/)
As of npm cli v8.3.0 (2021-12-09) this can be solved using the overrides field of package.json. As described in StriplingWarrior's answer
For example, the project has typescript version 4.6.2 as direct development dependency and awesome-typescript-loader that uses old version 2.7 of typescript. Here is how you can tell npm to use version 4.6.2 of typescript for awesome-typescript-loader:
{
"name": "myproject",
"version": "0.0.0",
"scripts": ...
"dependencies": ...
"devDependencies": {
"typescript": "~4.6.2",
"awesome-typescript-loader": "^5.2.1",
...
},
"overrides": {
"awesome-typescript-loader": {
"typescript": "$typescript"
}
}
}
If you don't use typescript as direct development dependency, then you have to write 4.6.2 instead of $typescript in overrides section:
{
"name": "myproject",
"version": "0.0.0",
"scripts": ...
"dependencies": ...
"devDependencies": {
"awesome-typescript-loader": "^5.2.1",
...
},
"overrides": {
"awesome-typescript-loader": {
"typescript": "~4.6.2"
}
}
}
For using the latest version of dependency:
{
"name": "myproject",
"version": "0.0.0",
"scripts": ...
"dependencies": ...
"devDependencies": {
"awesome-typescript-loader": "^5.2.1",
...
},
"overrides": {
"awesome-typescript-loader": {
"typescript": "latest"
}
}
}
Same overrides can be used for both dependencies and devDependencies.
If you're using npm version >5 but <8.3.0: edit your package-lock.json: remove the library from "requires" section and add it under "dependencies".
For example, you want deglob package to use glob package version 3.2.11 instead of its current one. You open package-lock.json and see:
"deglob": {
"version": "2.1.0",
"resolved": "https://registry.npmjs.org/deglob/-/deglob-2.1.0.tgz",
"integrity": "sha1-TUSr4W7zLHebSXK9FBqAMlApoUo=",
"requires": {
"find-root": "1.1.0",
"glob": "7.1.2",
"ignore": "3.3.5",
"pkg-config": "1.1.1",
"run-parallel": "1.1.6",
"uniq": "1.0.1"
}
},
Remove "glob": "7.1.2", from "requires", add "dependencies" with proper version:
"deglob": {
"version": "2.1.0",
"resolved": "https://registry.npmjs.org/deglob/-/deglob-2.1.0.tgz",
"integrity": "sha1-TUSr4W7zLHebSXK9FBqAMlApoUo=",
"requires": {
"find-root": "1.1.0",
"ignore": "3.3.5",
"pkg-config": "1.1.1",
"run-parallel": "1.1.6",
"uniq": "1.0.1"
},
"dependencies": {
"glob": {
"version": "3.2.11"
}
}
},
Now remove your node_modules folder, run npm ci (or npm install for old version of node/npm) and it will add missing parts to the "dependencies" section.
As of NPM v8.3, the correct way to deal with this is via the overrides section of your package.json file.
If you need to make specific changes to dependencies of your
dependencies, for example replacing the version of a dependency with a
known security issue, replacing an existing dependency with a fork, or
making sure that the same version of a package is used everywhere,
then you may add an override.
Overrides provide a way to replace a package in your dependency tree
with another version, or another package entirely. These changes can
be scoped as specific or as vague as desired.
To make sure the package foo is always installed as version 1.0.0 no
matter what version your dependencies rely on:
{
"overrides": {
"foo": "1.0.0"
}
}
There are a variety of other, more nuanced configurations allowing you to only override a package when it's a dependency of a particular package hierarchy. For more details, check out https://docs.npmjs.com/cli/v8/configuring-npm/package-json#overrides
The only solution that worked for me (node 12.x, npm 6.x) was using npm-force-resolutions developed by #Rogerio Chaves.
First, install it by:
npm install npm-force-resolutions --save-dev
You can add --ignore-scripts if some broken transitive dependency scripts are blocking you from installing anything.
Then in package.json define what dependency should be overridden (you must set exact version number):
"resolutions": {
"your-dependency-name": "1.23.4"
}
and in "scripts" section add new preinstall entry:
"preinstall": "npm-force-resolutions",
Now, npm install will apply changes and force your-dependency-name to be at version 1.23.4 for all dependencies.
For those using yarn.
I tried using npm shrinkwrap until I discovered the yarn cli ignored my npm-shrinkwrap.json file.
Yarn has https://yarnpkg.com/lang/en/docs/selective-version-resolutions/ for this. Neat.
Check out this answer too: https://stackoverflow.com/a/41082766/3051080
Nested replacement with an entirely different package
Most of the strategies outlined in the other answers here work well if you are just interested in overriding the package's version number, but in our case, we needed to find a way to override a nested npm sub-dependency with a different package altogether. For details on why you would ever want to do this, please refer to the following question:
How to override a nested npm sub-dependency with a different package altogether (not just different package version number)?
Specify the tarball directly
For nested replacement of a package with an entirely different package using the npm-force-resolutions strategy that others have mentioned, you just need to provide a link to the tarball where you would normally specify the overriding version number.
As an example, for the case of replacing the vulnerable package, ansi-html, with the fixed fork of this package, ansi-html-community, your resolutions section of package.json should look like this:
"resolutions": {
"ansi-html": "https://registry.npmjs.org/ansi-html-community/-/ansi-html-community-0.0.8.tgz"
}
To find the link to the tarball, use the following command, modifying your registry as necessary:
npm view ansi-html-community dist.tarball --registry=https://registry.npmjs.org/
Also, note that for npm-force-resolutions to work when you run npm install, you will need a preinstall entry under the scripts section of package.json:
"scripts": {
"preinstall": "npx npm-force-resolutions"
}
#user11153 's answer worked for me locally, but when trying to do a clean install (aka deleting node_modules), I would get:
npm-force-resolutions: command not found
I had to update the preinstall script to be:
"preinstall": "npm i npm-force-resolutions && npm-force-resolutions"
Which ensures that npm-force-resolutions package is installed before attempting to run it.
That being said, if you're able to use yarn instead, I would do that and then use #Gus 's answer.
I had an issue where one of the nested dependency had an npm audit vulnerability, but I still wanted to maintain the parent dependency version. the npm shrinkwrap solution didn't work for me, so what I did to override the nested dependency version:
Remove the nested dependency under the 'requires' section in package-lock.json
Add the updated dependency under DevDependencies in package.json, so that modules that require it will still be able to access it.
npm i
I was about to go down the npm-force-resolutions route but it seems that simply including the dependency in my own package.json fixed the problem for me.
I believe this worked in my case because the original dependency allows for patch versions of the dependency in question that I wanted to update. Thus by manually including a newer version it still fulfilled the dependency of the original dependency and will use the one I've manually added.
Example
Problem
I need to update plyr to version 3.6.9 from 3.6.8
Mine
package.json
{
"dependencies": {
"react-plyr": "^3.2.0"
}
}
React Plyr
package.json
{
"dependencies": {
"plyr": "^3.6.8"
}
}
Notice for the plyr dependency it starts with ^ this means it can accept any minor patches. You can learn more about that here:
https://docs.npmjs.com/about-semantic-versioning#using-semantic-versioning-to-specify-update-types-your-package-can-accept
Updating Mine
This updates the plyr dependency from my package.json.
package.json
{
"dependencies": {
"plyr": "^3.6.9",
"react-plyr": "^3.2.0"
}
}
Based on the rest of the answers, I provide the same solution, but I display the package.json, as I struggled a little bit on where to place the override and how.
{
"name": "my-app",
"version": "snapshot",
"scripts": {
"ng": "ng",
"build-dev": "ng build --configuration development",
},
"private": true,
"dependencies": {
"#angular/animations": "~14.2.9",
"#angular/common": "~14.2.9"
...
},
"devDependencies": {
"#angular-devkit/build-angular": "^14.2.8",
....
},
"overrides": {
"loader-utils#>2.0.0 <3": "2.0.4",
"loader-utils#>3.0.0 <4": "3.2.1"
}
}
For November 2022 "loader-utils" security vulnerability, it was requested to
use the version 2.0.4, if you are in the 2.X
use the version 3.2.1, if you are in the 3.X
And to verify
add the package.json the override tag
delete the package-lock.json
run "npm install"
run "npm audit"
Run this first
npm i -D #types/eslint#8.4.3
it will solve the issue