webpack build silently fails after Linaria update

Hi there,

I have a mysterious problem in one of my projects after updating to the current version of Linaria: The webpack build seems to crash, but it does not report any error - it just exits without writing anythin on disk.

I managed to track down the change in Linaria that causes the problem, I just can’t figure out what’s happening exactly. Thanks for having a look! 😅

Environment

• Linaria version: 4.2.2
• Bundler (+ version): webpack 5.75.0
• Node.js version: 19.1.0
• OS: ArchLinux

Description

I do not really understand what is happening - maybe an error that leads to a crash, but the error is then swallowed somehow?

I managed to track it down to https://github.com/callstack/linaria/pull/1086 (CC @Anber ): It starts working again when I pin @linaria/babel-preset to 4.2.2, or comment out the await mutex that was introduced there.

Reproducible Demo

I was unable to provide a minimal reproduction, as only one of my projects is affected, and I don’t know which code there causes it.

I created a branch with a reproduction here: https://github.com/kryops/vlight/tree/linaria-babel-preset-error

Just execute yarn, which should build everything.

The output is:

...
[BABEL] Note: The code generator has deoptimised the styling of /home/michael/git/vlight/node_modules/@mdi/js/mdi.js as it exceeds the max of 500KB.
[BABEL] Note: The code generator has deoptimised the styling of /home/michael/git/vlight/node_modules/@mdi/js/mdi.js as it exceeds the max of 500KB.
➤ YN0000: Done with warnings in 42s 859ms

(the [BABEL] message is repeated 4 times)

Nothing is written into the frontend/dist folder.

The successful build output on the main branch looks like this:

...
[BABEL] Note: The code generator has deoptimised the styling of /home/michael/git/vlight/node_modules/@mdi/js/mdi.js as it exceeds the max of 500KB.
[BABEL] Note: The code generator has deoptimised the styling of /home/michael/git/vlight/node_modules/@mdi/js/mdi.js as it exceeds the max of 500KB.
6 assets
774 modules
webpack 5.75.0 compiled successfully in 33886 ms
➤ YN0000: Done with warnings in 54s 906ms

(the [BABEL] message is repeated more than 4 times)

[Anber]

@garthenweb I’ve checked how Linaria works with esbuild. Half of the test cases don’t work. It means that if imported code is transpiled with esbuild, Linaria cannot resolve its dependency graph and detect unnecessary code. I’ll fix it asap.

[PierreGUI]

Trying to update from Linaria 2.3.1 I also experience this issue where webpack stops without error. When provided with the option progress, webpack gets stuck: 10% building 0/x entries 1/y dependencies 0/z modules

Looking at this issue, I suspect we have circular dependencies in our app too. So I ran dpdm --no-warning --no-tree ./src/*.ts and found only type dependencies in the report (the output with -T option is green ✅ ).
Since then, I’ve been looking for a reproduction case.

Setup

• Webpack 5.75
• Babel 7.13 with typescript preset
• React 18
• Linaria 4.3

Mini repro case

The smallest code to confuse Linaria’s build is the following:

App.ts

import { styled } from '@linaria/react'
import * as React from 'react'
import B from './B'

export const App = styled.div``

B.ts

import App from './App'

dpdm --no-warning --no-tree ./src/app.ts
✔ [3/3] Analyze done!
• Circular Dependencies
  1) src/A.ts -> src/B.ts
  
 dpdm -T --no-warning --no-tree ./src/app.ts
✔ [1/1] Analyze done!
• Circular Dependencies
  ✅ Congratulations, no circular dependency was found in your project.

PS: I’m also looking at more intricate examples because I feel this doesn’t give the full picture. I’ve been able to build similar code in some cases, but at some point it fails when the dependency tree grows. I have a hunch enum are part of the problem (because are type and value at the same time) maybe?