Reid Burke

In addition to pnpm supporting minimumReleaseAge in pnpm 10.16, Yarn has introduced a similar feature with npmMinimalAgeGate. There are some minor differences which mostly effect npmMinimumReleaseAgeExclude. This option is similar to pnpm’s minimumReleaseAgeExclude but also supports an exact match on package locators like @react-router/[email protected] or semver and micromatch globs like @react-router/node@^7.9.1, @react-router/node@npm:^7.9.1, @react-router/node@*, or @react-router/*.

Zoltan Kochan, following a wave of incidents where common npm packages including debug were compromised with a phishing attack last week and nx was compromised with a credential catcher a few weeks ago:

There have been several incidents recently where popular packages were successfully attacked. To reduce the risk of installing a compromised version, we are introducing a new setting that delays the installation of newly released dependencies. In most cases, such attacks are discovered quickly and the malicious versions are removed from the registry within an hour.

The new setting is called minimumReleaseAge. It specifies the number of minutes that must pass after a version is published before pnpm will install it. For example, setting minimumReleaseAge: 1440 ensures that only packages released at least one day ago can be installed.

Matt Brophy:

We landed our initial unstable implementation of middleware behind a future flag in 7.3.0. Since then, we’ve been iterating on the API/implementation and working closely with community members who adopted the unstable flag for alpha testing. We received a ton of valuable feedback from those folks that helped us move the API to an even better spot in the end.

We’re excited to finally stabilize these APIs in 7.9.0 behind the future.v8_middleware flag and can’t wait to see the interesting patterns folks come up with when using them. There are already a handful of useful middlewares available in remix-utils that are worth checking out!

Providing data from a parent to a child:

// app/root.tsx
const context = createContext<User>();

const userMiddleware: Route.MiddlewareFunction = ({ context }) => {
  let user = await getUser(request);
  context.set(userContext, user); // 👈 Provide data here
};

export const middleware = [userMiddleware];

export async function loader({ context }) {
  return { user: context.get(userContext) }; // 👈 Access data here
}

// app/routes/_index.tsx
export async function loader({ request }) {
  let user = context.get(userContext); // 👈 Access data here
  // ...
}

// app/root.tsx
const context = createContext<User>();

const userMiddleware: Route.MiddlewareFunction = ({ context }) => {
  let user = await getUser(request);
  context.set(userContext, user); // 👈 Provide data here
};

export const middleware = [userMiddleware];

export async function loader({ context }) {
  return { user: context.get(userContext) }; // 👈 Access data here
}

// app/routes/_index.tsx
export async function loader({ request }) {
  let user = context.get(userContext); // 👈 Access data here
  // ...
}

Short-circuiting child loaders with a redirect:

// app/routes/_auth.tsx
const requireUserMiddleware: Route.MiddlewareFunction = ({ context }) => {
  let user = await getUser(request);
  if (!user) {
    throw redirect("/login");
  }
  // ...
};

export const middleware = [requireUserMiddleware];

// app/routes/_auth.profile.tsx
export async function loader({ request }) {
  // ✅ This code will never run if there's no logged-in user
  let data = await getUserData(request);
  return data;
}

// app/routes/_auth.tsx
const requireUserMiddleware: Route.MiddlewareFunction = ({ context }) => {
  let user = await getUser(request);
  if (!user) {
    throw redirect("/login");
  }
  // ...
};

export const middleware = [requireUserMiddleware];

// app/routes/_auth.profile.tsx
export async function loader({ request }) {
  // ✅ This code will never run if there's no logged-in user
  let data = await getUserData(request);
  return data;
}