Allow CI Workflow Run

• approve CI run for commit: 05ee77e

Note: this should only be enabled once the PR is ready to go and can only be enabled by a maintainer

Allow CI Workflow Run

• approve CI run for commit: ecc4e18

Note: this should only be enabled once the PR is ready to go and can only be enabled by a maintainer

• Turbopack: add support for matching loaders on resource queries #88644 👈 (View in Graphite)
• canary

This stack of pull requests is managed by Graphite. Learn more about stacking.

Failing test suites

Commit: 4bb3e1d | About building and testing Next.js

pnpm test test/integration/telemetry/test/index.test.ts (turbopack) (job)

• Telemetry CLI > production mode > emits event when swc fails to load (DD)

expect(received).toMatch(expected)

Expected pattern: /NEXT_SWC_LOAD_FAILURE/
Received string:  "⚠ Attempted to load @next/swc-linux-x64-gnu, but an error occurred: Cannot load native addon because loading addons is disabled.
⚠ Attempted to load @next/swc-linux-x64-musl, but an error occurred: Cannot load native addon because loading addons is disabled.
⚠ Attempted to load @next/swc-wasm-nodejs, but it was not installed
⚠ Attempted to load @next/swc-wasm-web, but it was not installed
⨯ Failed to load SWC binary for linux/x64, see more info here: https://nextjs.org/docs/messages/failed-loading-swc·
> Build error occurred
Error: Failed to load SWC binary for linux/x64, see more info here: https://nextjs.org/docs/messages/failed-loading-swc

  at <unknown> (../dist/build/swc/index.js:318:38)
  "
  at Object.toMatch (integration/telemetry/test/index.test.ts:111:24)

pnpm test-dev-turbo test/development/acceptance-app/app-hmr-changes.test.ts (turbopack) (job)

• Error overlay - RSC build errors > Skipped in webpack > should handle successive HMR changes with errors correctly (DD)

Expected no visible Redbox but found one
header: Runtime TypeError
frame.join is not a function
description: frame.join is not a function
source: null

  58 |
  59 |           await session.patch(pagePath, originalPage)
> 60 |           await session.waitForNoRedbox()
     |           ^
  61 |         }
  62 |
  63 |         expect(

  at Object.<anonymous> (development/acceptance-app/app-hmr-changes.test.ts:60:11)

pnpm test-start-turbo test/e2e/app-dir/segment-cache/revalidation/segment-cache-revalidation.test.ts (turbopack) (job)

• segment cache (revalidation) > re-fetch visible links after a navigation, if needed (DD)

thrown: "Exceeded timeout of 120000 ms for a test.
Add a timeout value to this test to increase the timeout, if this is a long-running test. See https://jestjs.io/docs/api#testname-fn-timeout."

  248 |   })
  249 |
> 250 |   it('re-fetch visible links after a navigation, if needed', async () => {
      |   ^
  251 |     let act: ReturnType<typeof createRouterAct>
  252 |     const browser = await next.browser('/refetch-on-new-base-tree/a', {
  253 |       beforePageLoad(page) {

  at it (e2e/app-dir/segment-cache/revalidation/segment-cache-revalidation.test.ts:250:3)
  at Object.describe (e2e/app-dir/segment-cache/revalidation/segment-cache-revalidation.test.ts:7:1)

CodSpeed Performance Report

Merging this PR will not alter performance

_{Comparing sokra/query-condition (4bb3e1d) with canary (f67bc23)}

Summary

✅ 17 untouched benchmarks
⏩ 3 skipped benchmarks¹

Stats from current PR

✅ No significant changes detected

@sokra As you could have read in the discussions this very issue links to, I had already implemented this weeks ago in #87291. I gotta say that it's quite disappointing to go through the effort of fixing a long-standing issue, only to not even get a review on the PR that was mentioned in all of the right places, including ones this PR doesn't. Feel free to close my PR, unless you can find something useful in it, still.

For what it's worth, I agree with @bgw in that using exact string matching against query strings is essentially always the wrong choice, and should likely always be RegExp instead. Otherwise it immediately breaks once additional query parameters are added.

Overall I'm glad this finally got addressed, even at the cost of my own work getting discarded.

@jwueller I'm very sorry about that. I didn't see your PR, but it looks good. I rebased it and got some value-able test, doc and performance improvements => #88801

I think we need to improve our workflow of handling PRs, but I don't really know how. We have >1k open PRs and github doesn't do the best job in making them discoverable...

@sokra Thank you, I very much appreciate that! I'm happy to hear you got some mileage out of it still!

And I understand that it's hard to keep track of literally over a thousand PRs, of course. I'm honestly not sure how I'd deal with that either. Looking at those other issue keys, I'm assuming you came at it from an internal issue tracker. That probably made surfacing related work in other places harder as well.

Thanks for getting this over the line and huge thanks for @jwueller for the initial work. I've been waiting for this for almost 2 years now.

@sokra, how can we load files with the default/internal file/url loader that turbopack uses? E.g. if we have queries with ?url, how to load them as external URLs/files? I guess I can do it with not perhaps.

@kevva I've been thinking about referencing internal loaders too, but that seems like a separate problem. Maybe we could have a "spread-like" placeholder for those, that can be inserted into custom loader arrays.

As for URL loading, you can actually use this literal syntax with Turbopack, although I'm not sure if it's documented anywhere:

new URL("./asset.png", import.meta.url)

It gets replaced with the public URL during compile.

@jwueller, yeah it's somewhat documented here. But this configuration seems to work too:

'*.svg': {
  condition: { not: { query: '?url' } },
  loaders: [{ loader: '@svgr/webpack' }],
  as: '*.js',
}

@kevva Ah right, because it avoids matching to begin with, so the defaults still apply. I guess that's a decent workaround.

Interesting that the URL literal is only documented in the context of experimental URL imports. It worked for local paths for quite a while before that already, I'm pretty sure.

This PR also adds type: "asset" (#88788) that is slightly related.