I am working on a React app with a MySQLdb and am trying to deploy with Heroku. I have followed a guide closely and am using JAWS DB hook to connect my db to Heroku. I am running into this error when I run the "heroku open" command after pushing to heroku:
"Error: Cannot find module '/app/node_modules/mime/mime.js'. Please verify that the package.json has a valid "main" entry"
My package.json has mime.js installed as a devDependency. I have set the "main" line in my package.json to "index.js" as well.
Repo: https://github.com/AndrewCodesDontYaKnow/ReactCalc
Anyone have any experience with this type of issue? Thanks much.
I just had the same problem with a different module ("telebot" in my case)
I didn't figure out how to fix the issue (if anyone else finds this, I'd also like to know how to fix it), but I got it to work with a work around...
I copied the module source, and put it into my repo, and just used it as a local module...
(in my case I had by my .gitignore file ignore any "lib" folder, it gave me a hard time until i realized the lib folder from the telebot folder is just not getting uploaded to GitHub, and as such not getting to heroku, but after commenting it out, and getting it to upload, the local module worked as intended)
also, I don't think this is an actual answer, but I don't have the rep to comment, so I hope this helps
Related
I have been trying to deploy my project with AWS EB console, not CLI, and I have encountered this "Your WSGIPath refers to a file that does not exist." again and again. I changed the WSGIPath from application.py to awesomedonor/wsgi.py and I struggled to find typo in my django.config but I failed...So... I need you guys help!!
this is my EB status,
this is django.config. and last...
This is list of files and directory I try to upload, except venv, db.sqlite, and zip file.
It feels like the zip file does not contain the right structure. Please download the application version from EB console and unzip to ensure it contains the following structure.
....manage.py
....requirements.txt
....awesomedonor
........wsgi.py
hope this helps.
I've been getting this error while trying to create a script file to automate a little of the codePush deployment process.
Looking at all the information I could find online wasn't helping - In the script I echo'd the PWD to see that I am running the code-push release-react command from the correct location in my .sh file, I am including react-native as a package dependency in my package.json. Everything looked fine, but I was still getting the error.
Since I found the issue but couldn't find anything online to point to what the problem was, I'll post the answer below.
Upon playing with the scripts in my package.json I tried running npm install again to make sure everything was setup properly when I get an error that actually showed me my issue.
The problem was the JSON in my package.json had become corrupted - the syntax wasn't spot on. I had started playing with the json in the file and forgot to revert the changes I made when I finished and had an extra comma.
Now that almost a whole day is gone, I can get back to work.
I'm attempting to install PHP Code Sniffer for PhpStorm, but have been unable to get it to work. I've been following the steps here: https://confluence.jetbrains.com/display/PhpStorm/PHP+Code+Sniffer+in+PhpStorm
I added PHP Code Sniffer as a Composer dependency, and it now appears in the project directory. I then went to the code sniffer settings page, where I entered the path to the PHPCS.bat file. When I click Validate, I get an error message saying "Can not run PHP Code Sniffer".
Have I missed a step or is there a log somewhere with more information on what is not working?
I solved the same problem by editing the phpcs.bat file and replacing the paths:
PHPBIN=#php_bin#
with
PHPBIN=path\to\php.exe
and
"%PHPBIN%" "#bin_dir#\phpcs" %*
with
"%PHPBIN%" "path\to\phpcs" %*
I had the same issue, I solve it adding the php path to the PATH environment variables on windows. Because when it runs the scripts needs to run php and if it not present on the global path of windows will fail.
im running Hudson continuous integration for db unit.
when i run the job the console output is displaying the SUCCESS, but then why do the Parsed Console Output keep returning this error:
ERROR:Failed to parse console log :
log-parser plugin ERROR: Cannot parse log: Can't read parsing rules file:
i already installed the parse-log plugin & i already restarted the Hudson..
i installed the plugin using remote PC
any help and suggestion is appreciated. Thanks!
1) Place the Parser Rule File in the JENKINS_HOME location.
2) Configure that log parser console output in the Global COnfiguration settings and Name it.
3) Add this option in the Post Build Actions and Select the Name
ok silly me..
i forgot to configure the global configuration in hudson that link to the parser rule file..
problem solved.
I'm posting this in case anyone else has a specific case of this problem. This issue started when upgrading from 1.509.2 to 1.554.3... I had the parsing rules file in the win\system folder which was a known issue when running Jenkins as a service. Well I guess they fixed it by this version. I moved the parsing rules back into Jenkins Home folder and it worked fine again.
In the job configuration for a Jenkins 1.418 job (older versions are Hudson) on Windows, I am having trouble with "Archive the artifacts". In the box titled "Files to archive" I have
foo/**/Release/Install/App.exe
The error it gives me at configuration time is:
'foo//Release/Install/App.exe' doesn't match anything: 'foo' exists but not 'foo//Release/Install/App.exe'
Now, if I'm correct, ** is "search all subdirectories" as per ant. What is odd, is that no matter what I enter it tells me the top level folder exists (foo), but no other folder exists underneath it. Yet when I use the windows explorer to navigate, all my folders exist.
How can I troubleshoot this or fix it?
Update: I figured out a technique to troubleshoot - use the workspace browse features in hudson/jenkins to find what is visible and what is not visible. Turns out some directories had file permissions that blocked them being visible inside jenkins/hudson.
I had hudson configured to run a batch file, and my folder references were failing because of some errors in the batch files I was using. This was not a hudson problem, but a batch file problem. I saw the error and thought it was the problem because it was a reported error, but the real problem was a silent failure in a batch file.