No dist folder after successful build in Docker image

[runemadsen]

Bug report

Describe the bug

I have been battling the weirdest bug for a number of days now, and I have come to the conclusion that there's something really odd going on in my Keystone production builds. Basically, I have a keystone+next app that works perfectly in development. It also works perfectly when I run keystone build && keystone start on my Mac. However, when I run the same command inside of a Docker image based on the Node 12.18.4 image, I am getting a successful build but no dist folder. Weirdly, there is a .next folder for the Next app, so I know the build runs. Also, the output is successful:

ℹ Command: keystone build
✔ Validated project entry file ./index.js
✔ Initialised Keystone instance
info  - Creating an optimized production build  
info  - Compiled successfully
info  - Collecting page data  
info  - Finalizing page optimization  

Page                                Size     First Load JS
┌ ○ /                               5.92 kB        69.7 kB
├   └ css/8a993ca52536da0f6eb6.css  2.21 kB
├   /_app                           0 B            63.4 kB
├ ○ /404                            1.21 kB        64.6 kB
├ λ /page1                  30.4 kB        97.1 kB
├   └ css/23b850c60e4412572a8c.css  1.49 kB
├ λ /page2                   4.32 kB        68.1 kB
├   └ css/879338cbc4935188d40d.css  2.36 kB
└ λ /page2/[slug]            112 kB          179 kB
    └ css/0fa5f31c541f445e3fbe.css  4.76 kB
+ First Load JS shared by all       63.4 kB
  ├ chunks/commons.f838f3.js        12.5 kB
  ├ chunks/framework.e52e59.js      40.5 kB
  ├ chunks/main.520794.js           6.91 kB
  ├ chunks/pages/_app.7f1d39.js     2.74 kB
  ├ chunks/webpack.e06743.js        751 B
  └ css/78be484fc792a8368c86.css    3.65 kB

λ  (Server)  server-side renders at runtime (uses getInitialProps or getServerSideProps)
○  (Static)  automatically rendered as static HTML (uses no initial props)
●  (SSG)     automatically generated as static HTML + JSON (uses getStaticProps)
   (ISR)     incremental static regeneration (uses revalidate in getStaticProps)

✔ Exported Keystone build to ./dist

So, if something is going wrong, Keystone is not telling me. There is no dist folder, and I am getting Admin UI not generated when I try to run keystone start.

To Reproduce

I am using the suggested Dockerfile from the docs:

ARG NODE_VERSION=12.18.4
ARG DUMB_INIT_VERSION=1.2.2

# Build container
FROM node:${NODE_VERSION}-alpine AS build
ARG DUMB_INIT_VERSION

WORKDIR /usr/local/app

RUN apk add --no-cache build-base python2 yarn && \
    wget -O dumb-init -q https://github.com/Yelp/dumb-init/releases/download/v${DUMB_INIT_VERSION}/dumb-init_${DUMB_INIT_VERSION}_amd64 && \
    chmod +x dumb-init
ADD . /usr/local/app

RUN npm install && npm run build

RUN ls -al

# Runtime container
FROM node:${NODE_VERSION}-alpine

WORKDIR /usr/local/app

COPY --from=build /usr/local/app /usr/local/app

RUN ls -al

EXPOSE 3000
CMD ["./dumb-init", "npm", "run", "start"]

You will see that I added some ls commands, which, right after keystone successfully finishes the build shows no dist folder.

Expected behaviour

I am expecting to see a dist folder or for Keystone to tell me there was an error.

System information

Docker with the node:12.18.4-alpine image

[runemadsen]

After another day of debugging, I realized this was caused by an lowercase/uppercase import problem. My import looked like this:

import './graphData';

But the file is named graphdata.js.

To replicate: Create a file with camelcase naming and import it with lowercase naming on linux. The Keystone build will succeed with ✔ Exported Keystone build to ./dist, but no dist folder is created.

[Echooff3]

I'm running into a similar issue. Is there a way to run the build with more detail? A debug or verbose setting?

[bladey]

Keystone 5 has officially moved into active maintenance mode as we push towards the next major new version Keystone Next, you can find out more information about this transition here.

In an effort to sustain the project going forward, we're cleaning up and closing old issues such as this one. If you feel this issue is still relevant for Keystone Next, please let us know.