Huge News!Announcing our $40M Series B led by Abstract Ventures.Learn More
Socket
Sign inDemoInstall
Socket

@remix-run/eslint-config

Package Overview
Dependencies
Maintainers
0
Versions
1045
Alerts
File Explorer

Advanced tools

Socket logo

Install Socket

Detect and block malicious and high-risk dependencies

Install

@remix-run/eslint-config - npm Package Versions

1
105

0.0.0-nightly-4a957276b-20240918

Diff

mjackson
published 0.0.0-nightly-3d7966f52-20240916 •

mjackson
published 0.0.0-nightly-825f70ebd-20240914 •

mjackson
published 0.0.0-experimental-ee1a1f9db •

mjackson
published 0.0.0-nightly-d9a607635-20240910 •

mjackson
published 2.12.0 •

Changelog

Source

v2.12.0

Date: 2024-09-09

What's Changed

Future Flag for Automatic Dependency Optimization (unstable)

You can now opt-in to automatic dependency optimization during development by using the future.unstable_optimizeDeps future flag. For details, check out the docs at Guides > Dependency optimization. For users who were previously working around this limitation, you no longer need to explicitly add routes to Vite's optimizeDeps.entries nor do you need to disable the remix-dot-server plugin.

Improved Single Fetch Type Safety (unstable)
  • If you were already using single-fetch types:
    • Remove the "@remix-run/react/future/single-fetch.d.ts" override from tsconfig.json > compilerOptions > types
    • Remove defineLoader, defineAction, defineClientLoader, defineClientAction helpers from your route modules
    • Replace UIMatch_SingleFetch type helper with the original UIMatch
    • Replace MetaArgs_SingleFetch type helper with the original MetaArgs

Then you are ready for the new type safety setup:

// vite.config.ts

declare module "@remix-run/server-runtime" {
  interface Future {
    unstable_singleFetch: true; // 👈 enable _types_ for single-fetch
  }
}

export default defineConfig({
  plugins: [
    remix({
      future: {
        unstable_singleFetch: true, // 👈 enable single-fetch
      },
    }),
  ],
});

For more information, see Guides > Single Fetch in our docs.

Updates to Single Fetch Revalidation Behavior (unstable)

With Single Fetch, re-used routes will now revalidate by default on GET navigations. This is aimed at improving caching of Single Fetch calls in the simple case while still allowing users to opt-into the previous behavior for more advanced use cases.

With this new behavior, requests do not need special query params for granular route revalidations out of the box - i.e., GET /a/b/c.data

There are two conditions that will trigger granular revalidation and will exclude certain routes from the single fetch call:

  • If a route opts out of revalidation via shouldRevalidate
  • If a route defines a clientLoader
    • If you call serverLoader() from your clientLoader, that will make a separate HTTP call for just that route loader - i.e., GET /a/b/c.data?_routes=routes/a for a clientLoader in routes/a.tsx

When one or more routes are excluded from the Single Fetch call, the remaining routes that have loaders are included as query params. For example, when navigating to /a/b/c, if A was excluded, and the root route and routes/b had a loader but routes/c did not, the Single Fetch request would be GET /a/b/c.data?_routes=root,routes/b.

For more information, see Guides > Single Fetch in our docs.

Minor Changes

  • @remix-run/dev - New future.unstable_optimizeDeps flag for automatic dependency optimization (#9921)

Patch Changes

  • @remix-run/dev - Handle circular dependencies in modulepreload manifest generation (#9917)
  • @remix-run/dev - Fix dest already exists build errors by only moving SSR assets to the client build directory when they're not already present on disk (#9901)
  • @remix-run/react - Clarify wording in default HydrateFallback console warning (#9899)
  • @remix-run/react - Remove hydration URL check that was originally added for React 17 hydration issues and we no longer support React 17 (#9890)
    • Reverts the logic originally added in Remix v1.18.0 via #6409
    • This was added to resolve an issue that could arise when doing quick back/forward history navigations while JS was loading which would cause a mismatch between the server matches and client matches: #1757
    • This specific hydration issue would then cause this React v17 only looping issue: #1678
    • The URL comparison that we added in 1.18.0 turned out to be subject to false positives of it's own which could also put the user in looping scenarios
    • Remix v2 upgraded it's minimal React version to v18 which eliminated the v17 hydration error loop
    • React v18 handles this hydration error like any other error and does not result in a loop
    • So we can remove our check and thus avoid the false-positive scenarios in which it may also trigger a loop
  • @remix-run/react - Lazy Route Discovery: Sort /__manifest query parameters for better caching (#9888)
  • @remix-run/react - Single Fetch: Improved type safety (#9893)
  • @remix-run/react - Single Fetch: Fix revalidation behavior bugs (#9938)
  • @remix-run/server-runtime - Do not render or try to include a body for 304 responses on document requests (#9955)
  • @remix-run/server-runtime - Single Fetch: Do not try to encode a turbo-stream body into 304 responses (#9941)
  • @remix-run/server-runtime - Single Fetch: Change content type on .data requests to text/x-script to allow Cloudflare compression (#9889)

Updated Dependencies

Changes by Package

Full Changelog: v2.11.2...v2.12.0

mjackson
published 2.12.0-pre.4 •

mjackson
published 2.12.0-pre.3 •

mjackson
published 2.12.0-pre.2 •

mjackson
published 0.0.0-nightly-4083f718a-20240906 •

SocketSocket SOC 2 Logo

Product

  • Package Alerts
  • Integrations
  • Docs
  • Pricing
  • FAQ
  • Roadmap
  • Changelog

Packages

npm

Stay in touch

Get open source security insights delivered straight into your inbox.


  • Terms
  • Privacy
  • Security

Made with ⚡️ by Socket Inc