1.16.0 new dev server not finishing rebuilds

[dmarkow]

What version of Remix are you using?

1.16.0

Are all your remix dependencies & dev-dependencies using the same version?

• Yes

Steps to Reproduce

For me, #5663 was caused by triggering a new rebuild while the old one was still running. As of 1.16.0, the same action is now causing a new issue.

Rebuilds work perfectly fine around 50% of the time when I save a file, then trigger another save within the 3-4 seconds my rebuild takes. However, the other 50% or so, the rebuilds start and never finish.

Saving a file once:

# Terminal output:
3:43:28 PM remix.1   |  💿 File changed: app/routes/expenses/route.tsx
3:43:28 PM remix.1   |  💿 Rebuilding...
3:43:32 PM remix.1   |  💿 Rebuilt in 3.9s
3:43:32 PM remix.1   |  Waiting for app server (631c8e7c)
3:43:32 PM remix.1   |  > remix-serve build/index.js
3:43:34 PM remix.1   |  Remix App Server started at http://localhost:3000 (http://192.168.1.111:3000)
3:43:34 PM remix.1   |  App server took 1.1s
3:43:34 PM remix.1   |  > HMR

# Browser console:
invoices:33 💿 File changed: app/routes/expenses/route.tsx
invoices:33 💿 Rebuilding...
invoices:33 💿 Rebuilt in 3.8s
invoices:49 [HMR] Component changed [app/routes/expenses/route.tsx]
invoices:70 [HMR] Updated accepted by remix:manifest

Saving multiple times before a rebuild is complete (e.g. save, notice a typo, immediately fix and save again):

# Terminal output, no output after this
3:51:03 PM remix.1   |  💿 File changed: app/routes/expenses/route.tsx
3:51:04 PM remix.1   |  💿 Rebuilding...
3:51:05 PM remix.1   |  💿 File changed: app/routes/expenses/route.tsx
3:51:05 PM remix.1   |  💿 Rebuilding...

# Browser console, no output and my changes never load in. Even refreshing the browser
# shows the old build. Have to fully stop and restart remix.
invoices:33 💿 File changed: app/routes/expenses/route.tsx
invoices:33 💿 Rebuilding...
invoices:33 💿 File changed: app/routes/expenses/route.tsx
invoices:33 💿 Rebuilding...

Expected Behavior

Remix dev server should allow multiple overlapping saves and always produce the latest result.

Actual Behavior

Dev server stops providing new builds. Future saves still show the "Rebuilding..." output, but none of the rebuilds ever finish.

[pcattori]

There's a race condition in the "dev ready" logic. The dev server should start listening for updated manifest before it writes server files to disk. Currently, if your app server restart is fast enough, it can ping the dev server with new manifest before dev server updates its own internal build hash.

This is the "fix race condition: listen for new manifest before writing the files" from our Roadmap item for the dev server

[pcattori]

The cause is that I forgot to cancel previous build when rebuilds are kicked off 🤦

Tracking this as its own task within the dev server Roadmap item

[JackHowa]

Thanks for tracking this! is there a good previous version to use where we're not seeing this? I tried going back to 1.15.0 but then css did not seem to load as expected. With ^1.16.0, I'm restarting the server to pick-up classname changes sometimes.

    "@remix-run/css-bundle": "^1.16.0",
    "@remix-run/node": "^1.16.0",
    "@remix-run/react": "^1.16.0",
    "@remix-run/serve": "^1.16.0",
    "@remix-run/dev": "^1.16.0",

[uSkizzik]

The better question is when will the fix come out? It's absolutely unbearable to work with Remix for me without the dev server properly refreshing. Even less so when I'm running the sass compiler every time I start the dev server.

[pcattori]

@uSkizzik @JackHowa you can already use the unreleased improvements from dev, by targeting the @nightly tag on npm for Remix deps (make sure you update all of your Remix deps to the same version).

[uSkizzik]

@ uSkizzik @ JackHowa you can already use the unreleased improvements from dev, by targeting the @nightly tag on npm for Remix deps (make sure you update all of your Remix deps to the same version).

Upgraded to latest nightly build and now I can't even open up any page because of a dev server error - Cannot read properties of undefined (reading 'pathname')

TypeError: Cannot read properties of undefined (reading 'pathname')
    at Object.createPath (D:\Skizzium\Websites And Services\skizzium-client\node_modules\@remix-run\router\history.ts:544:3)
    at Component (D:\Skizzium\Websites And Services\skizzium-client\node_modules\react-router-dom\index.tsx:422:50)
    at renderWithHooks (D:\Skizzium\Websites And Services\skizzium-client\node_modules\react-dom\cjs\react-dom-server.node.development.js:5724:16)
    at renderForwardRef (D:\Skizzium\Websites And Services\skizzium-client\node_modules\react-dom\cjs\react-dom-server.node.development.js:5908:18)
    at renderElement (D:\Skizzium\Websites And Services\skizzium-client\node_modules\react-dom\cjs\react-dom-server.node.development.js:6071:11)
    at renderNodeDestructiveImpl (D:\Skizzium\Websites And Services\skizzium-client\node_modules\react-dom\cjs\react-dom-server.node.development.js:6170:11)
    at renderNodeDestructive (D:\Skizzium\Websites And Services\skizzium-client\node_modules\react-dom\cjs\react-dom-server.node.development.js:6142:14)
    at renderNode (D:\Skizzium\Websites And Services\skizzium-client\node_modules\react-dom\cjs\react-dom-server.node.development.js:6325:12)
    at renderChildrenArray (D:\Skizzium\Websites And Services\skizzium-client\node_modules\react-dom\cjs\react-dom-server.node.development.js:6277:7)
    at renderNodeDestructiveImpl (D:\Skizzium\Websites And Services\skizzium-client\node_modules\react-dom\cjs\react-dom-server.node.development.js:6207:7)
    at renderNodeDestructive (D:\Skizzium\Websites And Services\skizzium-client\node_modules\react-dom\cjs\react-dom-server.node.development.js:6142:14)
    at renderElement (D:\Skizzium\Websites And Services\skizzium-client\node_modules\react-dom\cjs\react-dom-server.node.development.js:6037:9)
    at renderNodeDestructiveImpl (D:\Skizzium\Websites And Services\skizzium-client\node_modules\react-dom\cjs\react-dom-server.node.development.js:6170:11)
    at renderNodeDestructive (D:\Skizzium\Websites And Services\skizzium-client\node_modules\react-dom\cjs\react-dom-server.node.development.js:6142:14)
    at renderForwardRef (D:\Skizzium\Websites And Services\skizzium-client\node_modules\react-dom\cjs\react-dom-server.node.development.js:5925:5)
    at renderElement (D:\Skizzium\Websites And Services\skizzium-client\node_modules\react-dom\cjs\react-dom-server.node.development.js:6071:11)

Turns out I had a to prop on the wrong element.

[natac13]

I have been using the nightly build for the last few days and I am still getting the dev server stuck on rebuilding.
Could there be something I am doing wrong?

[lucascurti]

We are seeing the same behavior in v1.16.0 and the old dev server

[pcattori]

@natac13 were you also seeing this issue with the old dev server? or with unstable_dev?

[natac13]

@pcattori Nope. I have another project in remix which has yet to do this to me. It is on 1.15 of remix where this newer project is started on 1.16.
One key difference is the newer project I used pnpm instead of npm. However, I did try to run the dev server with npm and got the same result. I don't think I did an install with npm though.

Also the newer project is trying to make use of firebase for the auth.

Those are the only differences I can think of which are notable.

Also both projects are using the remix dev server. The current one with the issues is deploying to AWS via SST with the @remix-run/node package for stuff. Whereas the other project, which has not done this yet (I have not worked on it for a bit either) is deploying to vercel with their new @vercel/remix packaged used in place of @remix-run/node

Let me know if you need more info.

[roniaxe]

@pcattori Nope. I have another project in remix which has yet to do this to me. It is on 1.15 of remix where this newer project is started on 1.16. One key difference is the newer project I used pnpm instead of npm. However, I did try to run the dev server with npm and got the same result. I don't think I did an install with npm though.

Also the newer project is trying to make use of firebase for the auth.

Those are the only differences I can think of which are notable.

Also both projects are using the remix dev server. The current one with the issues is deploying to AWS via SST with the @remix-run/node package for stuff. Whereas the other project, which has not done this yet (I have not worked on it for a bit either) is deploying to vercel with their new @vercel/remix packaged used in place of @remix-run/node

Let me know if you need more info.

I'm also on a project using @vercel/remix instead of @remix-run/node. In my case, I see the logs

[HMR] Component changed [app\root.tsx]
(index):71 [HMR] Updated accepted by remix:manifest

But my UI is not updated at all. I have to refresh the page.

[brandonpittman]

This happens under 1.16.0 even with the old dev server (using @remix-run/node).

[TheGreatAxios]

Any update on how to temporarily fix this until a fix hits stable?

[ddm50]

Was under the impression that the nightly versions have it fixed. Haven't tested myself.

[TheGreatAxios]

Was under the impression that the nightly versions have it fixed. Haven't tested myself.

Thanks, will give it a test run 👍

[sarahrobichaud]

I am using Remix 1.16.0 and tailwindcss

In my case my css builds were causing 2 rebuilds like this when triggering postcss:

💿 File changed: app\routes\_app.shed.tsx
💿 Rebuilding...
💿 File changed: app\styles\global.css
💿 Rebuilding...

And it would get stuck in at Rebuilding...

When I upgrading to nightly the terminal output was slightly different

💿 File changed: app\routes\_app.shed.tsx
💿 Rebuilding...
💿 File changed: app\styles\global.css
💿 Rebuilding...
💿 Rebuilt in 217ms
✘ [ERROR] The build was canceled


💿 Rebuilt in 90ms

it stopped getting stuck but hot reload wasn't triggered on css only changes.

I got the expected behavior back (where I get the updated view even when changing only a class) by switching to @remix-run/dev@nightly and running my css builds separately from dev:*

[natac13]

An observation I have notice is that is seems to hang on rebuilding when I do a small tailwind change, like add a single class.
Most of the React, loader, action, other typescript code changes seem to rebuild as expected. But on small tailwind changes I have notice it happens a lot.

[brandonpittman]

I've had most of my issues when changing Vanilla Extract's .css.ts files. I think it's mostly a problem of timing. If I disable the autosave in my editor, it's a lot harder for this issue to come up.

[pcattori]

Rebuild hanging should be fixed by #6295
CSS-only HMR should be fixed by #6374

Both of these fixes are available on latest nightly if anyone wants to try it out.

[dmarkow]

@pcattori Just tested it out and the hanging does seem to be resolved, thank you!

Unfortunately, rebuild times slowed down a bunch again too -- 1.16.0 + my caching PR had me at 12s for a clean build and 3-4s for rebuilds, nightly is now 16s for a clean build and 7-8s for rebuilds. Not sure if that warrants opening another issue or anything since it's not in a released version.

[pcattori]

@dmarkow yea I think perf optimization are a separate issue that we should look into

[devarsh]

Nightly build stopped generating classes for css modules - which works perfectly with 1.16.0

[NicolasStuff]

I just disabled the auto-save and I save manually on vs-code the prevent this problem. I hope the fix will come soon.

[pcattori]

Nightly build stopped generating classes for css modules - which works perfectly with 1.16.0

This sounds like an issue unrelated to this one. Could you open a separate issue?

@markdalgleish ^ you might be interested in this one

[github-actions]

🤖 Hello there,

We just published version 1.16.1-pre.0 which involves this issue. If you'd like to take it for a test run please try it out and let us know what you think!

Thanks!

[markdalgleish]

@devarsh I wasn't able to reproduce your CSS issue against both 0.0.0-nightly-360e77e-20230516 and 1.16.1-pre.0, with default settings and with future.unstable_dev set to true. If you're still having problems, are you able to share a repro as a new issue?

[devarsh]

So I realised you've to enable the flags in nightly build to generate css bundle. Which I assumed we didn't had to since it was enabled by default with 1.6.1

But there is still issue when I'm trying to import components exported from index.js - css bundle is not generated but classes are applied- I'm referring to css modules

[markdalgleish]

You shouldn't need to enable flags in the nightly build, just like in v1.16.0. I've been able to get CSS Modules working in the nightly release without enabling any flags.

The second issue you mentioned sounds like this esbuild issue mentioned in the Remix docs:

When using CSS-bundling features, you should avoid using export * due to an issue with esbuild's CSS tree shaking.

If you're using export * to re-export components that import bundled CSS files, you should migrate these to explicit named re-exports, .e.g.

-export * from "./Button";
+export { Button } from "./Button";

[github-actions]

🤖 Hello there,

We just published version 1.16.1 which involves this issue. If you'd like to take it for a test run please try it out and let us know what you think!

Thanks!