linaria: webpack build silently fails after Linaria update

@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.

+1

I have encountered this issue too. I am using npm package inversify which has a circular require inside it. After some investgations into internal codes of linaria, I make it work by copying the default rules of EvalRule

https://github.com/callstack/linaria/blob/master/docs/CONFIGURATION.md#:~:text=The default setup is%3A

Actually the default rules in the document is not the default rules in the code. That’s confusing.

The await mutex takes me a lot of debugging time to find it because everything become idle. Is there any way to make a “timeout” to inform possible circular deps?

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?

@garthenweb maybe it does. If you have a lot of packages that are transpiled with esbuild, Linaria may struggle with resolving the whole dependency tree. I’m going to add esbuild to the list of tested compilers and check if it works or not. I’ll let you know in a day.

Thanks for the hints, that makes sense. When exploring the behaviour I found similarities to what you describe. If we can remove the unneeded parsing, the issue would reduce quite a lot. It might be sufficient for 95% of the cases. In combination with a proper warning in case it still happens it is most probably easy enough to work around.

I will try to come up with an example repo as soon as I find time for it 😃

Hi @kryops!

Probably, you have a circular dependency somewhere. However, it is not a legit reason to crash without any error messages 😃