#slow (10 seconds+) dev server starts and hot reload not working
1 messages · Page 1 of 1 (latest)
how many routes does your app have?
and could you share your remix.config.js and your package.json scripts? want to see if/how you use unstable_dev and serverDependenciesToBundle
i'm facing the same on 1.16.1, here's the config
/** @type {import('@remix-run/dev').AppConfig} */
module.exports = {
appDirectory: "app",
assetsBuildDirectory: "public/build",
cacheDirectory: ".cache",
future: {
unstable_dev: true,
v2_errorBoundary: true,
v2_meta: true,
v2_normalizeFormMethod: true,
v2_routeConvention: true,
},
ignoredRouteFiles: [
"**/.*",
"**/*.spec.ts",
"**/*.spec.tsx",
"**/*.test.ts",
"**/*.test.tsx",
],
mdx: async (_filename) => {
const [remarkGfm] = await Promise.all([
import("remark-gfm").then((mod) => mod.default),
]);
return {
remarkPlugins: [remarkGfm],
};
},
publicPath: "/build/",
serverPlatform: "node",
watchPaths: ["public/locales"],
};
we have about 300 route files
@lime pendant how many of your routes are mdx?
only 4
@lime pendant is your repo publicly viewable?
what's the difference between remix watch and remix dev in terms of the esbuild options?
if not, would you be willing to screenshare
is your repo publicly viewable?
unfortunately, no... we're backed by VC and it's a closed source SAAS for payroll processing
they both use the same underling compiler with the same configs
but with remix watch, we're seeing only about 2s compilation time whereas remix dev takes up to 6s
are you using unstable_dev?
yeah
and the 6s is just the rebuild? or also the time spent waiting for you app server to be ready?
remix watch with unstable_dev=false -> 2s
remix dev with unstable_dev=true -> 6s
all for the remix assets initial/subsequent builds
what version of Remix are you on?
1.16.1 now
can you share the terminal output when initial build and subsequent rebuild occurs?
my app server, i am using the same setup like what kent was doing on the video with you
yeah can
you can also try nightly since this just landed: https://github.com/remix-run/remix/pull/6455
remix watch with unstable_dev=false
the only difference between unstable_dev and old dev server is that unstable_dev does a separate compilation pass to detect loader changes for HDR. but that should be done in parallel to normal (re)build
remix watch with unstable_dev=true
this is missing output I would expect from unstable_dev . Like the Waiting for app server messages
and it also never shows Built in Xms, just Rebuilt in Xms
do i have to use switch to remix dev when i do unstable_dev=true?
What do you mean by "switch"? were you using remix watch?
correct
yes remix watch is not useful with unstable_dev. you should use remix dev instead
let me share the screenshot with that
can you share your package.json scripts for dev?
i wrap the commands into commands and use concurrently to run them
you probably don't need to do most of that anymore with unstable_dev since you can use -c flag
i tried migrating to it, then my team told me today that they were seeing 12s on their weaker macbook, then i just moved it back to remix watch with unstable_dev=false like 4 hours ago
yea we're still optimizing unstable_dev (hence the unstable part 😅), but like I said, you can try out nightly as that has one perf improvement that should make a big difference
this is what my team member shared with me, doing remix dev with unstable_dev=true, their macbook is m1 lower spec
do you know what version of Remix they were running when this was screenshotted?
same, i upgraded them to 1.16.1, asked them to run a script i prepared for them which will remove node_modules/.cache/build and reinstall node_modules
do you know how fast/slow the old dev server with remix watch was for them?
remix watch is about 5s to 6s for them
Yea I think with nightly it should speed things up considerably for them
this is the script i had when we were on remix dev with unstable_dev=true
1 question i have, my current server.ts which contains expressjs, i'm using esbuild to compile myself which i'm also using watch mode (with bundle=false though), it emits the compiled JS in like 100ms, it's like the incremental build is really super fast
would it be possible for remix to do the same?
Seems like dev:worker shouldn't be there
dev:worker is a bullmq background worker which we're running to test our cron and scheduled jobs
oh only dev:server is the one that's related to remix assets builder
not sure what your suggestion is here. we already use esbuild in incremental watch mode
is it because of remix does bundle everything into build/index.js?
the majority of the build time is spent in CSS and browser JS, not server (unless you have .* in your serverDependenciesToBundle)
because our own express and backend code, when using esbuild with this config, it compiles the changed file in under 100ms which allows us to restart our express server in under 1s
the majority of the build time is spent in CSS and browser JS, not server (unless you have .* in your serverDependenciesToBundle)
ahhh the css and js bundling for browser
but like I said, try out nightly and see if that speeds things up for you
might see 20%-50% improvement for initial builds, and maybe some improvement for rebuilds
that's great man!!!!
hahah don't thank me yet! try it out first and let's see what the real perf improvements are
yeah trying it now
do i only install @remix-run/dev nightly? or the other packages also need to follow the same?
with nightly and remix dev + unstable_dev=true
with 1.16.1 and remix dev + unstable_dev=true
yeah it's about 18% improvement
i'm curious to see if that 18% is the same for you coworkers with less powerful machines or if it scales differently for them
let me ask them to try out tomorrow
@lime pendant are you relying on Remix to compile CSS for you? e.g. built-in support for tailwind or vanilla extract or postcss
this is the interesting part, we're using mantine which uses css-in-js, and we're stuck with react 17 with remix-island to workaround the assets 404 issue upon app error being thrown
that's why right now we also can't move to remix dev to use the HMR + HDR as remix-island requires us to wrap the outlet inside <div id="root"></div
@full maple can you try commenting our your serverDependenciesToBundle, and running remix dev to see how much speed up you get from that?
I'm also wondering how much your build is slowed down by CSS compilation since you are using emotion, chakra, and tailwindcss
@full maple is your repo publicly viewable?