My Expo project requires the latest version of react-native-svg library to render my SVGs correctly. Currently it's version 9.3.5
From package-json.lock, I see that my current Expo SDK 32 has version 8.0.10 listed.
"dependencies": {
"react-native-svg": {
"version": "8.0.10",
"resolved": "https://registry.npmjs.org/react-native-svg/-/react-native-svg-8.0.10.tgz",
"integrity": "sha512-gsG5GUdvlox67+ohLnq3tZSqiYBmz4M5lKKeUfnJZ8EPrMMS5ZgaVj7Zcccee1VvINS5xQaoenUJdha/GEo34w==",
"requires": {
"color": "^2.0.1",
"lodash": "^4.16.6",
"pegjs": "^0.10.0"
}
}
}
I have tried just installing latest react-native-svg alongside Expo by using
npm install react-native-svg#9.3.5
However, when running the app I get an error:
Tried to register two views with the same name RNSVGRect
So how can I force Expo to use the latest version? I don't see any react-native-svg dependencies anywhere and changing the package-lock.json directly doesn't seem like a good idea.
Short answer to my question is: you can't. At least not without some ugly hacks that are more trouble than they're worth.
The good news is that SDK 33 now comes with "react-native-svg": "~9.4.0" as a dependency and this is almost the latest version as of this writing.
Related
i'm using Electron for the first time and have a problem.
I used a sample to make an app with Angular and Electron. When I changed a little bit i made a build to test if things are right. Since that i made a lot of new functions and updates. Now when i try to build/package my app, i got the same version i have made at the beginning and not the version i'm seeing when i made npm-run-all -p electron:serve ng:serve what i'm doing wrong?
I have used electron-forge, i have used electron-packager and them both got the same old version builded. And i don't know what to do now.
try with extraMetadata in your package.json :
{
"build": {
...,
"extraMetadata": {
"version": "X.Y.Z"
},
...
}
I'm building a react native app using Expo and Expo Go to test it on an android device. It has been working flawlessly until today. I encoutered an error on one of my components with this kind of error:
Attempt to invoke virtual method 'android.graphics.drawable.Drawable android.graphics.drawable.Drawable$ConstantState.newDrawable(android.content.res.Resources)' on a null object reference
Solution seemed to me to clear cache yarn cache clean. I also cleared cache on the Expo Go app. But this led me to Metro Bundler failing with this error:
Android Bundling failed 1279ms
While trying to resolve module `immer` from file `H:\my_project\app\node_modules\#reduxjs\toolkit\dist\redux-toolkit.cjs.production.min.js`, the package `H:\my_project\app\node_modules\immer\package.json` was successfully found. However, this package itself specifies a `main` module field that could not be resolved (`H:\my_project\app\node_modules\immer\dist\immer.esm.mjs`. Indeed, none of these files exist:
* H:\my_project\app\node_modules\immer\dist\immer.esm.mjs(.native|.android.ts|.native.ts|.ts|.android.tsx|.native.tsx|.tsx|.android.js|.native.js|.js|.android.jsx|.native.jsx|.jsx|.android.json|.native.json|.json)
* H:\my_project\app\node_modules\immer\dist\immer.esm.mjs\index(.native|.android.ts|.native.ts|.ts|.android.tsx|.native.tsx|.tsx|.android.js|.native.js|.js|.android.jsx|.native.jsx|.jsx|.android.json|.native.json|.json)
When checking H:\my_project\app\node_modules\immer\dist\, I do find an immer.esm.mjs file but no H:\my_project\app\node_modules\immer\dist\immer.esm.mjs\ folder with an index file in it.
So I tried to manually remove node_modules/ and reinstall packages with yarn, restart the Expo server, doing all this after restarting my machine, even ran expo upgrade, removed .expo/, removed yarn.lock, but I keep getting the same error.
This leaves me quite confused. Thank you for your suggestions on what to do.
Here are the dependencies versions used as in my package.json:
"#reduxjs/toolkit": "^1.8.1",
"#types/react-redux": "^7.1.22",
"expo": "~45.0.0",
"react": "17.0.2",
"react-native": "0.68.2",
"react-redux": "8.0.1",
"redux": "4.2.0"
Fix
As suggested in this redux-toolkit issue, there seems to be an issue with immer version 9.0.13. Temporary fix suggested there is working for me, adding immer#9.0.12 to my resolutions in packages.json:
"resolutions": {
"immer": "9.0.12"
}
Update
This PR on immer resolved this issue (9.0.14). I can confirm the above fix isn't needed anymore on my side. Looks like my bad luck came from some breaking changes being pushed on a minor release.
I have built a custom NodeJS module in C++, and I would like to use that in my electron app.
The module compilation using node-gyp works fine, and it copies the files in a dedicated directory. I can also install it by referring to the folder in my package.json file.
However, when I run the application, I get the following error:
(node:20800) UnhandledPromiseRejectionWarning: Error: The module '\?\D:\GitProjects\addon-test\local_node_modules\zeelicensenode\zeelicensenodejsaddon.node'
was compiled against a different Node.js version using
NODE_MODULE_VERSION 93. This version of Node.js requires
NODE_MODULE_VERSION 103. Please try re-compiling or re-installing
The module is compiled on the same Windows machine I am running the application and has only one NodeJS version installed.
D:\GitProjects\addon-test> node --version
v16.13.2
As per the electron documentation, it uses a different ABI than the native NodeJS binary, so they suggest to build the module in a different way. Following that documentation, I updated the make.ps1 file of C++ module as follows:
make.ps1
$env:Path="$($env:APPDATA)\npm;$($env:Path)"
npm install -g node-gyp
node-gyp clean
node-gyp configure
$env:HOME="$($env:USERPROFILE)\.electron-gyp;$($env:HOME)"
node-gyp build --target=18.1.0 --arch=x64 --dist-url=https://atom.io/download/electron
copy -Verbose .\build\Release\zeelicensenodejsaddon.node .\dist
In my electron application, I have the following dependencies:
package.json
"dependencies": {
"#quasar/extras": "^1.0.0",
"core-js": "^3.6.5",
"quasar": "^2.0.0",
"vue": "^3.0.0",
"vue-router": "^4.0.0",
"zeelicensenodejs": "file:local_node_modules/zeelicensenode"
},
"devDependencies": {
"#quasar/app": "^3.0.0",
"electron": "^18.1.0",
"electron-rebuild": "^3.2.7"
}
The local_node_modules/zeelicensenode folder contains the declaration file, package.json file, zeelicensenodejsaddon.node file and a JS file that exports the module. The JS file has these lines:
const license = require('./zeelicensenodejsaddon');
module.exports = license;
NODE_MODULE_VERSION 103 refers to the current NodeJS version (18.x), but I do not understand where it is coming from. I have NodeJS 16.x installed on my machine, and as per the Electron's release information, Electron v18.1.0 also has NodeJS 16.x.
Is there anything I am missing to make this custom module work with Electron?
I've been refactoring some of our AWS lambda functions and with this most recent version I am getting the following error:
"Payload": "{\"errorMessage\":\"Cannot find module '../vendor/endpoint-cache'\",\"errorType\":\"Error\",\"stackTrace\":[\"Function.Module._load (module.js:474:25)\",\"Module.require (module.js:596:17)\",\"require (internal/module.js:11:18)\",\"Object.<anonymous> (/var/task/node_modules/aws-sdk/lib/core.js:76:18)\",\"Module._compile (module.js:652:30)\",\"Object.Module._extensions..js (module.js:663:10)\",\"Module.load (module.js:565:32)\",\"tryModuleLoad (module.js:505:12)\",\"Function.Module._load (module.js:497:3)\"]}"
This module is within the vendor folder of the aws-sdk node module.
I checked the deployment artifacts to make sure that the folder exists and I've tried downgrading to the older version of the aws-sdk that was being used before.
Dependencies in package.json:
"dependencies": {
"aws-sdk": "^2.59.0",
"moment": "^2.22.2",
"underscore": "^1.8.3"
},
The build server runs npm-install and then
$path = Get-Location
$thisProject = "$($path)\pathToProject\*"
Compress-Archive -Path $thisProject -DestinationPath thisProject.zip
Been stuck on this for a while so any help is greatly appreciated.
I ran into this issue a few months back. Turns out I needed to make sure the package lock file was included in the project and had the aws-sdk version set
I had this issue yesterday, I solved it by removing the aws-sdk in the package.json & deleting + reinstalling my node_modules folder. Hope this solves your problem.
I think the aws-sdk is already included by default.
I actually encountered the same problem. And in my case the reason was in the Compress-Archive function, run on Windows. If I pack lambda with Compress-Archive, then Lambda call fails with the error in question above. But if I unpack .zip and pack with regular Windows "send to compressed directory" - everything works fine. I've found some similar issue in PowerShell github space, which made me think this is a common problem.
The problem was fixed in one of the latest releases of PowerShell Core (not sure about classic PowerShell). I'm not sure about the exact release which fixes this problem, but it was there in v.6.1, and in v.6.2.2 it's gone.
The recommended approach to specifying the SDK you want in a Lambda function is to create a lambda layer with your desired version. See here: https://aws.amazon.com/blogs/compute/working-with-aws-lambda-and-lambda-layers-in-aws-sam/
I'm allways running into this exception when I try to build my app with the sencha commandline tools. However, other apps seem to work fine. What am I missing?
UPDATE
I figured out it has something to do with the fact that I want my buildPath to be outside of the app directory. My section in the app.json looks like this:
"buildPaths": {
"production": "../deploy/frontenddemo/production",
"testing": "../deploy/frontenddemo/testing",
"package": "../deploy/frontenddemo/package",
"native": "../deploy/frontenddemo/native"
},
If I change it to:
"buildPaths": {
"production": "build/production",
...
},
Everything works as expected. I don't know why. It should be possible to have the builds outside the app directory I guess.
Ok, after a lot of try and error. I found the root cause of this issue.
My app.json looked like this:
"archivePath": "../deploy/frontenddemo/archive/",
"buildPaths": {
"testing": "../deploy/frontenddemo/testing",
"production": "../deploy/frontenddemo/production",
"package": "../deploy/frontenddemo/package",
"native": "../deploy/frontenddemo/native"
},
The problem with this structure is that both archive and builds produce a directory "sencha" outside of the configured path. Meaning they both create ../deploy/frontenddemo/sencha
with different contents. I wonder if that is documented somewhere?
The fix was easy. I just changed the paths to this:
"archivePath": "../deploy/frontenddemo/archive/",
"buildPaths": {
"testing": "../deploy/frontenddemo/builds/testing",
"production": "../deploy/frontenddemo/builds/production",
"package": "../deploy/frontenddemo/builds/package",
"native": "../deploy/frontenddemo/builds/native"
},
I've had previous issues deploying directly to a web server such as MAMP, or even Mac's default web server, in ~/Sites/
Have you tried changing your deployment directory to something other then MAMP, and then manually copy/paste it over?
Also, what exact version of the SDK are you using? 2.1 beta 3 was released a bit ago, as well as a new Sencha Cmd 3.0.0.122 (used to be called Sencha SDK Tools).
Forum Announcement: Sencha Touch 2.1.0 Beta 3 is available