ERROR: Cannot find module '../../../core/server/storage/base'
necevil opened this issue · 5 comments
Hey guys.
Attempting to get this module up and running inside of a docker container.
I have a reasonable amount of experience with Docker and have had a lot of luck getting a full ghost environment up and running locally (and also setup with a full ci pipeline for production).
I am running based off of the official ghost:0.11.3 image which works flawlessly without the module added. I did a fresh NPM install of the module when I created the Dockerfile to build the container. Here's the config:
Debian Jessie
Ghost v0.11.3
Node v4.7.2
NPM v2.15.11
ghost-storage-adapter-s3 v1.2.0
That being the case, my latest attempt to integrate the ghost-storage-adapter-s3 has failed with the following error:
ERROR: Cannot find module '../../../core/server/storage/base'
ghost |
ghost | IncorrectUsage: Cannot find module '../../../core/server/storage/base'
ghost | at Error.IncorrectUsage (/usr/src/ghost/core/server/errors/incorrect-usage.js:3:18)
ghost | at Object.getStorage (/usr/src/ghost/core/server/storage/index.js:36:19)
ghost | at setupMiddleware (/usr/src/ghost/core/server/middleware/index.js:126:44)
I shelled a new terminal inside of the container and verified that the /usr/src/ghost/node_modules/ghost-storage-adapter-s3/
DOES exist.
Then I shifted over to check to make sure that my copy functionality properly copied the contents also into: /usr/src/ghost/content/storage/s3
ALSO Exists and all contents appear to be in the folder.
After verifying the above, I added / installed vim inside of the container in an effort to inspect the source of the error (which now existed in two places since the above mentioned copy).
Since was in /usr/src/ghost/content/storage/s3 I figured I would mess with that one first. I found the following line:
var _base = require('../../../core/server/storage/base');
And changed it to the absolute path:
var _base = require('/usr/src/ghost/core/server/storage/base');
Then I cd'd over to /usr/src/ghost/node_modules/ghost-storage-adapter-s3/ to edit index.js over there. Code was the same so I replaced the line exactly as mentioned above.
Next I exited the container and did a docker ps, no container running.
Did a docker run to bring the container back up and it booted back up properly.
Still trying to figure out WHY it happened, if I knew I would fix it and submit a PR but figured I would bring it to your attention incase its happening to others. For now I am going to patch my Dockerfile to copy an alternate version of the index.js file overtop of the one causing the problems to quiet it down on myside (until I know for sure that its happening to everyone and not just docker peeps).
Thanks for the comprehensive report!
If you have /usr/src/ghost/core/server/storage/base.js and /usr/src/ghost/content/storage/s3/index.js I don't understand why relatively requiring ../../../core/server/storage/base from index.js would not work.
Still working on this one, will let you know how it goes.
Excited to get this sorted out, looks like a great plugin. Thanks for the efforts Colin!
So. The first time I ran the patched version of the index.js file (with the absolute path) inside of the container I was not properly importing my ghost config file which utilized the S3 storage option (hence it ran fine).
Once I brought the ghost-s3 container up with a correct config file that utilized the S3 Storage block, I still received:
ghost-s3 | ERROR: Cannot find module 'bluebird'
ghost-s3 |
ghost-s3 | IncorrectUsage: Cannot find module 'bluebird'
ghost-s3 | at Error.IncorrectUsage (/usr/src/ghost/core/server/errors/incorrect-usage.js:3:18)
ghost-s3 | at Object.getStorage (/usr/src/ghost/core/server/storage/index.js:36:19)
ghost-s3 | at setupMiddleware (/usr/src/ghost/core/server/middleware/index.js:126:44)
ghost-s3 | at /usr/src/ghost/core/server/index.js:188:9
ghost-s3 | From previous event:
ghost-s3 | at init (/usr/src/ghost/core/server/index.js:183:8)
ghost-s3 | at makeGhost (/usr/src/ghost/core/index.js:11:12)
ghost-s3 | at Object.<anonymous> (/usr/src/ghost/index.js:12:1)
ghost-s3 | at Module._compile (module.js:409:26)
ghost-s3 | at Object.Module._extensions..js (module.js:416:10)
ghost-s3 | at Module.load (module.js:343:32)
ghost-s3 | at Function.Module._load (module.js:300:12)
ghost-s3 | at Function.Module.runMain (module.js:441:10)
ghost-s3 | at startup (node.js:139:18)
ghost-s3 | at node.js:990:3
Currently working on two possibilities.
One is that it is related to the differences between packages written in ES2015 when referred to by modules written in something other than ES2015, there is an answer over on stackoverflow by user "Belgor" on the topic, about half way down and not a popular answer: http://stackoverflow.com/questions/9023672/how-do-i-resolve-cannot-find-module-error-using-node-js
The other is that it has something to do with the installation of the modules as global vs otherwise.
Inside of the container I have fully removed the entire ghost node_modules folder and done a fresh npm install. I have also done that full ghost npm install with the npm install -g (global flag).
That returned the same result so I then proceeded to re-add Bluebird and the other dependencies (again as global). Same result.
My container env=development
Will post further findings as I run into them.
Ok it seems like this was a permissions error inside of docker.
While my container that I used to work with the project includes some specific files required for my use case anyone else who runs into a similar error should try to chown the directories associated with ghost (and / or the storage/s3 directory).
Add the following to your Dockerfile (after the point you install your S3 package):
RUN chown -R user:user /usr/src/ghost/
I noticed that the official ghost container (on docker hub) runs a chown after all of its packages are installed so after doing the same I had success. Since I have been trouble shooting this for so many days I am going to run back through the process to make sure I am attributing the fix properly as soon as I get a few extra minutes.
Okay, am closing as it appears this issue isn't related to this library.