Dockerfile build failure > 14

[walshms]

Summary

I've encountered an issue where running npm run build completes fine, but running that inside a Dockerfile fails due to an error with @lit-labs/nextjs. The error looks like this:

9.692 Failed to compile.
9.692
9.692 ./node_modules/@babel/runtime/helpers/interopRequireDefault.js
9.692 Module parse failed: 'import' and 'export' may appear only with 'sourceType: module' (2:0)
9.692 File was processed with these loaders:
9.692  * ./node_modules/imports-loader/dist/cjs.js
9.692  * ./node_modules/next/dist/build/webpack/loaders/next-swc-loader.js
9.692 You may need an additional loader to handle the result of these loaders.
9.692 | /*** IMPORTS FROM imports-loader ***/
9.692 > import "@lit-labs/ssr-react/enable-lit-ssr.js";
9.692 |
9.692 | function _interopRequireDefault(e) {
9.692
9.692 Import trace for requested module:
9.692 ./node_modules/@babel/runtime/helpers/interopRequireDefault.js
9.692 ./node_modules/next-auth/next/middleware.js
9.692 ./node_modules/next-auth/middleware.js

The error comes from the next.config.js file on line 18:

module.exports = withLitSSR(nextConfig);

If I remove withLitSSR, everything is fine, and the build succeeds on both my machine, and the Docker build.

I don't think we actually need Lit SSR, and removing it should be possible for our project, but I would need to justify this to the team. Is there a workaround for this, or should I tell everyone we should remove SSR?

Additional information

To recreate this:
Build locally, observe success:

> npm install
> npm run build

Build Docker, observe failure:

> docker build .

Example

https://github.com/walshms/nextjs-example

[icyJoseph]

Ok, so the problem is that: @lit-labs/nextjs, hijacks the middleware file, adding:

import '@lit-labs/ssr-react/enable-lit-ssr.js'

To the top of the middleware file. And that causes the issue in the Docker container build step. Removing middleware, fixes the issue.

Why exactly, does it break in the Docker container, I think has to do with some detection made by the build step, while compiling the middleware, but gimme some time to put a seal on that.

Edit: I initially though the issue was the custom page extensions, but not, the problem is somehow the middleware getting that import statement, which ends with .js

[icyJoseph]

Adding, this to withLitSSR (making a local copy):

          exclude: [/next\/dist\//, /node_modules/],

Also fixes the issue. Kind of strange, why is next-auth getting targeted...

[ryanwalters]

We are running into the same issue with @lit-labs/nextjs. Unfortunately, we need to keep our middleware.ts file, and neither of the configurations listed below fix the issue:

const withLitSSR = require('@lit-labs/nextjs')({
  webpackModuleRulesExclude: [/next\/dist\//, /node_modules/],
});

const withLitSSR = require('@lit-labs/nextjs')({
  exclude: [/next\/dist\//, /node_modules/],
});

@icyJoseph Maybe I'm misunderstanding where to place the code snippet you provided? exclude does not appear to be an option for withLitSSR().

Also maybe worth mentioning, according to the docs the webpackModuleRulesExclude option defaults to [/next\/dist\//, /node_modules/].

Edit: lit/lit#4905 seems to align with the suggestion from @icyJoseph.

Edit 2: The issue for us turned out to be a combination of the default regex used for the webpackModuleRulesTest option, /\/pages\/.*\.(?:j|t)sx?$|\/app\/.*\.(?:j|t)sx?$/ (note the "app" portion of the regex), and our Dockerfile's WORKDIR which was /app. This was causing @lit-labs/nextjs to process all files in the application, overriding the value of the webpackModuleRulesExclude option which would have otherwise excluded the node_modules directory.

After updating our Dockerfile's WORKDIR to something else, our builds started working.

# Stage 1: Install dependencies
FROM base AS deps
WORKDIR /workdir # <-- changed from /app
COPY package.json package-lock.json* ./