Postinstall does not resolve a relative "DOWNLOAD_DIR" correctly #548
Comments
|
Extra Information: could you provide debug output? (while using the latest version, which currently is edit: also, does |
|
Thanks for the quick response! 7.0.0 works. There is no debug output as such, because the tests are running. The issue is that the download is not taking place on npm i. It is taking place when the first test file requiring mongo-memory-server is run. If I use the later versions (including e.g. 7.4.1 or 8.0.0-beta.2) the npm i hangs for a long time at the step before completing the install. |
i dont quite know but i think this step is actually downloading the package itself, not executing the postinstall also, if you want to prevent runtime download, you can use option
that should not really matter, just setting the environment variable should do it (if the testing engine passes through the variables, from what i know jest & mocha pass them through)
then theoretically |
|
7.3.6 doesn't work. If I set {runtimeDownload: false}, there is no download but also the test does not run at all, it just hangs there. These are the further config settings: Debug output with 8.0.0-beta.2 |
you dont need to define that, by default it will use the home directory if it already exists and is wanted, otherwise will use the
is that output from the tests / single run or from postinstall and could you provide the opposite if possible (to compare paths)? also, because it is in a node-docker container, what it the setup? is it a custom dockerfile that uses for now, i dont actually see a problem with the storage paths PS: i wrapped the log you provided in a collapsible / spoiler / details |
It is a custom dockerfile using
Unfortunately I don't understand what you are asking. This debug output comes from running the tests inside the docker container with debug activated. The output provided above came immediately before the package download which took place before the running of the first test, despite it having apparently downloaded once before, on npm i. This leads me to believe that it has something to do with the caching.
When I ran 7.0.0 without the
Thanks, I will keep this in mind in the future. |
thanks, this clarified that the output was from the tests, could you try replacing
this leads me to believe that somhow the CWD is messed up at postinstall and also $HOME is not quite correct - could you provide your dockerfile? |
Ran 8.0.0-beta.2 with
After further investigtation I have found that this problem is happening with Debug output on npm run test with 8.0.0-beta.2 |
my guess is this log is from running it on the host machine (macos / osx / darwin)? totally forgot that npm 7.x does not log any script output anymore, please try running |
|
Hi, sorry for the delay, I managed to corner a colleague to help me debug and it was in fact a problem on our side. Long story short (as clearly stated in the docs :/) the root needs to be specified in the downloadDir path: Thanks a lot for your prompt and dedicated support! It is very much appreciated. |
bascially, the binary was installed to the wrong user? |
|
The downloadDir path was incorrectly specified (it was "./node_modules/.cache" instead of "/home/node/node_modules/.cache"). As a result, Our Dockerfile splits the images into base, builder and test. We ran Dockerfile# Base -----------------
FROM node:14.17.5 AS base
WORKDIR /home/node
# Builder -----------------
FROM base AS builder
# Install all dependencies
COPY package*.json ./
RUN npm install
# test -----------------
FROM base AS test
ENV IS_CONTAINER=1
# Copy app source and dependencies
COPY --chown=node:node . .
COPY --from=builder --chown=node:node /home/node/node_modules ./node_modules
USER node
CMD ["npm", "run", "test"] |
so from my understanding it should have resolved correctly:
did the path maybe get overridden by |
This comment has been minimized.
This comment has been minimized.
|
i just tried with your dockerfile in a test project, and i could reproduce your problem because the downloadDir path was not absolute, it somehow got resolved to |
|
reopen, because the actual problem was found |
hasezoey
changed the title
We just copy the node_modules from that image without using it as the base for the next image. Wasn't my call to construct it that way, so can't be sure why. It works like this though ;)
That was also my understanding, which is why I thought it was a problem at your end, but after logging into the container and searching for the binary, we discovered that it was indeed in /root/.cache and not ./node_modules/.cache. Once we changed the downloadDir to specify /home/node/node_modules/.cache, the binary was being correctly cached in node_modules. |
|
fixed with 8f16a2a in this issue will stay open until this fix is merged into master |
|
🎉 This issue has been resolved in version 7.4.3 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
|
🎉 This issue has been resolved in version 8.0.0-beta.6 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
|
@hasezoey I am using mongodb-memory-server-core v8.0.2 and don't think this is properly fixed. I invoke the download using jest and see that the download path is still global (/root/.cache) instead of local (node_modules). |
|
@ChrisLahaye please provide how you set your custom DOWNLOAD_DIR option, guessing from the log, it does not appear to be set it found the package.json at also, if you want to download to local edit:
guessing from this message, it seems like your issue is not related to this issue, because yours it at runtime and not in postinstall, so maybe open a new issue referencing this issue |
Versions
package: mongo-memory-server
What is the Problem?
The db is not downloading and caching on install, but rather downloads the first time it is required in a test file.
Tried 8.0.0-beta.1 and beta.2, but the same issue.
With 7.0.0-beta.43 it works as expected.
Do you know why it happens?
no
The text was updated successfully, but these errors were encountered: