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.
Related
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/
So, I'm working on a robotframework test project, and the goal is to run several test suites in parallel. For this purpose, pabot was chosen as the solution. I am trying to implement it, but with little success.
My issue is: after installing Pabot (which, I might say, I did by cloning the project and running "setup.py install", instead of using pip, since the corporate proxy I'm behind has proven an obstacle I can't overcome), I created a new directory in the project tree, moved some suites there, and ran:
pabot --processes 2 --outputdir pabot_results Login*.robot
Doing so results in the following error message:
2018-10-10 10:27:30.449000 [PID:9676] [0] EXECUTING Suites.LoginAdmin
2018-10-10 10:27:30.449000 PID:400 EXECUTING Suites.LoginUser
2018-10-10 10:27:30.777000 PID:400 FAILED Suites.LoginUser
2018-10-10 10:27:30.777000 [PID:9676] [0] FAILED Suites.LoginAdmin
WARN: No output files in "pabot_results\pabot_results"
Output:
[ ERROR ] Reading XML source '' failed: invalid mode ('rb') or filename
Try --help for usage information.
Elapsed time: 0 minutes 0.578 seconds
Upon inspecting the stderr file that was generated, I have this message:
Traceback (most recent call last):
File "C:\Python27\Lib\site-packages\robotframework-3.1a2.dev1-py2.7.egg\robot\running\runner.py", line 22, in
from .context import EXECUTION_CONTEXTS
ValueError: Attempted relative import in non-package
Apparently, this has to do with something from the runner.py script, which, if I'm not mistaken, came with the installation of robotframework. Since manually modifying that script does not seem to me the optimal solution, my question is, what am I missing here? Did I forget to do anything while setting this up? Or is this an issue of compatibility between versions?
This project is using Maven as the tool to manage dependencies. The version I am running is 3.5.4. I am using a Windows 10, 64bit system; I have Python 2.7.14, and Robot Framework 3.1a2.dev1. The Pabot version is 0.44. Obviously, I added C:\Python27 and C:\Python27\Scripts to the PATH environment variable.
Edit: I am also using robotframework-maven-plugin version 1.4.0.8, if that happens to be relevant.
Edit 2: added the error messages in text format.
I believe I've come across an issue similar when setting up parallel execution on my machine. Firstly I would confirm that pabot is installed using pip show robotframework-pabot.
Then you should define the directory your results are going to using -d.
I then modified the name of the -o to Output.xml to make it easy to identify.
This is a copy of the code I use. Runs optimally with 8 processes
pabot --processes 8 -d results -o Output.xml Tests
Seems that you stumbled on a bug in the prerelease version of robot framework (3.1a2.dev1).
Please install a release version of robot framework. For example 3.0.4.
Just in case anyone happens to stumble upon this issue in the future:
Since I can't use pip, and I tried a good deal of workarounds that eventually made things more unstable, I ended up saving my project and removing everything Python-related from my system, so as to allow me to install everything from scratch. In a Windows 10, 64bit system, I used:
Python 2.7.14
wxPython 2.8.12.1, win64, unicode, for py27
setuptools 40.2.0 (to allow me to use the easy_install command)
Robot Framework 3.0.4
robotremoteserver 1.1
Selenium2Library 3.0.0
and Pabot version 0.45.
I might add that, when installing the Selenium2Library the way I described above, it eventually tries to download some things from the pip repositories - which, if you have a proxy, will cause you trouble. I solved this problem by browsing https://pypi.org/simple/selenium/, manually downloading the 2.53.6 .tar.gz file, then extracting it and running setup.py install on the command line.
PS: Ideally, though, anyone should be able to use proxy settings from the command line (--proxy http://user:password#server:port) to get pip and then use it; however, for some reason, probably related to network security configurations that I didn't want to lose time with, this didn't work in my case.
I did my first development in a Win7 machine, then switched to a Mac when I got that, which was great due to the speed of building with ember server running. I've been keeping everything in a Git repo. Everything works fine running ember server from my Mac.
Now, when I do a fresh clone from the repo on my Win7 computer, then do npm install and bower install (both of which complete fine), when I run ember server next, I get a bunch of errors saying ENOTEMPTY, directory not empty (path, blah blah blah).
It's complaining about some folder in the tmp directory, which the server command is creating and putting stuff into all by itself, so I don't know what it's complaining about.
I've been finagling with this about 5 different times now, but without success.
Ember CLI version is 0.1.1
Ember version is 1.6
Here's an example of one of the errors, but they're all similar (and similarly unhelpful):
ENOTEMPTY, directory not empty 'c:\Dev\star\tmp\remover-tmp_dest_dir-sRc08q1q.tm
p\templates'
Error: ENOTEMPTY, directory not empty 'c:\Dev\star\tmp\remover-tmp_dest_dir-sRc0
8q1q.tmp\templates'
at Object.fs.rmdirSync (fs.js:623:18)
at rmkidsSync (c:\Dev\star\node_modules\ember-cli\node_modules\rimraf\rimraf
.js:247:11)
at rmdirSync (c:\Dev\star\node_modules\ember-cli\node_modules\rimraf\rimraf.
js:237:7)
at fixWinEPERMSync (c:\Dev\star\node_modules\ember-cli\node_modules\rimraf\r
imraf.js:150:5)
at Function.rimrafSync [as sync] (c:\Dev\star\node_modules\ember-cli\node_mo
dules\rimraf\rimraf.js:216:26)
at Remover._remove (c:\Dev\star\node_modules\ember-cli\node_modules\broccoli
-file-remover\index.js:46:10)
at c:\Dev\star\node_modules\ember-cli\node_modules\broccoli-file-remover\ind
ex.js:60:14
at Array.forEach (native)
at c:\Dev\star\node_modules\ember-cli\node_modules\broccoli-file-remover\ind
ex.js:59:12
at $$$internal$$tryCatch (c:\Dev\star\node_modules\ember-cli\node_modules\rs
vp\dist\rsvp.js:470:16)
file added bootstrap.min.js
file added favicon.ico
file added sb-admin-2.js
Okay, I managed to do something that worked. I had forgotten I needed to disable Windows Indexing on my tmp folder at least (I did it for the whole cloned project):
Windows Key, type "Indexing Options"
Click the drive, then Modify
Uncheck places you don't want indexed (like the tmp folder)
If you use Sublime, go to Perferences --> Settings - User and add the following:
"folder_exclude_patterns":
[
"tmp/*",
],
Finally, I just had to keep doing ember server, stopping it, and doing it again until it build successfully (took around 5 tries).
Building off: Ember-cli - Bower not installing properly
I just upgraded from ember-cli 0.0.40 to 0.1.2 and when I run the ember server I also have an issue with moment. 48 JSHint Errors of Bad option: 'moment'.
After JSHint is done letting me have it, I did a bad path error for loader.js:
Path or pattern "vendor/loader.js/loader.js" did not match any files
Error: Path or pattern "vendor/loader.js/loader.js" did not match any files
at Object.multiGlob (/home/mikeumus/Downloads/RentalGeek/Development/portola-workon29oct/node_modules/ember-cli/node_modules/broccoli-concat/node_modules/broccoli-kitchen-sink-helpers/index.js:221:13)
at /home/mikeumus/Downloads/RentalGeek/Development/portola-workon29oct/node_modules/ember-cli/node_modules/broccoli-concat/index.js:62:32
at $$$internal$$tryCatch (/home/mikeumus/Downloads/RentalGeek/Development/portola-workon29oct/node_modules/ember-cli/node_modules/rsvp/dist/rsvp.js:470:16)
at $$$internal$$invokeCallback (/home/mikeumus/Downloads/RentalGeek/Development/portola-workon29oct/node_modules/ember-cli/node_modules/rsvp/dist/rsvp.js:482:17)
at $$$internal$$publish (/home/mikeumus/Downloads/RentalGeek/Development/portola-workon29oct/node_modules/ember-cli/node_modules/rsvp/dist/rsvp.js:453:11)
at $$rsvp$asap$$flush (/home/mikeumus/Downloads/RentalGeek/Development/portola-workon29oct/node_modules/ember-cli/node_modules/rsvp/dist/rsvp.js:1531:9)
at process._tickCallback (node.js:419:13)
Before upgrading to ember-cli#0.1.2 I was getting an includes error for ember-cli-simple-auth. I did do ember g ember-cli-simple-auth and that's nifty, but the above error persists.
Make sure to follow the steps on the releases page to have a solid upgrade.
Specifically in your case, this is likely caused by an app.import in your Brocfile.js. One of the big changes was that bower components were moved to /bower_components instead of /vendor. That error says that something is trying to import loader.js from the vendor directory.
It could be caused by you trying to import it in your Brocfile or due to ember-cli not being updated properly in your node_modules folder. If it still references the old version, it will try to import from vendor/ instead of bower_components. To fix that, just rm -rf node_modules and npm install to reinstall the modules.
The releases page mentions how to clear your npm cache to reinstall everything if you are still having trouble.
I'm using a koji to build a package. In error, it's saying:
Error: Package: pacemaker-cluster-libs-1.1.10-14.el6.x86_64 (build)
Requires: libcman.so.3()(64bit)
What does it exactly mean?
'libcman.so' is in the package 'cluster'. Then I built the clusterlib, and add it into my build, but didn't fix the problem after I put 'cluster' into 'BuildRequires' since another problem 'no package found for cluster' came out.
I think I'm not on the correct track.
I didn't fix it, but did some work around to avoid it. It's '.so', so I don't think the python module I build really need it here. So I commented it out from the spec file. and Just ensure I have these packages installed at the server before I install the new python module.