Bump @remix-run/node from 1.11.1 to 1.12.0

[dependabot]

Bumps @remix-run/node from 1.11.1 to 1.12.0.

Release notes

Sourced from @​remix-run/node's releases.

v1.12.0

We've got a few nice bug fixes and improvements in this release. You can catch those in the individual package changelogs below, but what we really want to talk about today is a huge step forward in a much nicer developer experience for you. Let's get to it!

An early peek at a new dev server 👀

Since the early days of Remix, the remix dev command has been limited by its association with the built-in Remix app server while remix watch simply watched your files and spit out builds, but doesn't handle requests like some other tools. But one of the major benefits of this is that Remix lets you own your server. While this is a very powerful core feature of our architecture, it presented a few challenges for local development. If you own your server, how can we build a dev server that is flexible enough to work for your specific setup?

Our first answer was … we don't. Don't try to be clever, don't over-abstract anything. Simply run the remix watch, spit out files, and have <LiveReload> tell the browser to reload. But we didn't know if your app server was done rebooting the server code! And in the case of remix dev with remix-serve, we didn't reboot the server, we simply wiped out the node require cache as a budget server side HMR.

There were a few downsides for local development with this:

1. Clearing the require cache wipes in-memory references, such as database connections or in-memory caches. This means you have to use workaround like sticking flags on global to persist anything stored in memory across rebuilds.
2. Getting the web socket port to remix watch and over to your app server in a different process (whether it was express, netlify def, vercel dev, etc.) and using it in LiveReload was a lot of unnecessary friction.
3. It makes implementing popular new dev features like hot-module replacement (HMR) much more difficult to implement in a way that works consistently across all app servers.
4. Each rebuild writes new files to build/ and public/build/. As these files are not removed (unless the dev server crashes or is gracefully terminated), thousands of files could accumulate as the dev server ran. This causes performance issues and could be confusing when debugging.

To start addressing these issues, we decided to take a new approach. This release gives you early access to our new dev server and start making incremental improvements to your local development flow.

Please note that this is an unstable feature and a work-in-progress. But we think there are good reasons to opt in right away!

At this stage, the idea is to spin up the dev server alongside your normal Remix app server:

# spin up the new dev server
remix dev
Spin up your app server in parallel.
This can be done in a separate terminal or with a tool like concurrently.
nodemon ./server.js

Our dev server will build your app in development mode and then rebuild whenever any app files changes. It will also wait for your app server to signal that it's "ready" before triggering a reload in your browser.

No more wiping in-memory caches. No more weird hacks to keep your database alive. A fresh, clean slate for each rebuild.

While this may seem like a relatively small change, but it's removes a huge barrier for future DX improvements for local development. We think you're going to love what we're working on next 🔥🔁

Limitations

The new dev server does not currently work with Remix App Server (i.e. remix-serve command) because Remix App Server hardcodes NODE_ENV=production.

Rest assured, when the new dev server stabilizes it will support Remix App Server as well.

Configuring the unstable_dev server

To enable the new dev server with all defaults, set the unstable_dev future flag to true:

// remix.config.js
module.exports = {
</tr></table> 

... (truncated)

Changelog

Sourced from @​remix-run/node's changelog.

1.12.0

Patch Changes

• Updated dependencies:
  • @remix-run/server-runtime@1.12.0

Commits

• f215e47 chore: Update version for release (#5318)
• 74df911 chore: Update version for release (pre) (#5317)
• 4edd740 chore: Update version for release (pre) (#5260)
• 0189c54 chore: Update version for release (pre) (#5256)
• 686e20d chore: Update version for release (pre) (#5243)
• 57004e3 chore(remix-node): update jsdoc for FileUploadHandlerOptions' filter (#3777)
• 57f41c2 fix(remix-node): export JsonFunction as type instead of as value (#5204)
• c08f30f feat(remix-node): add getFilePath& remove methods to NodeOnDiskFile (#4...
• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[penx]

@dependabot rebase

[penx]

@dependabot recreate