next.js

ff756b2c - Turbopack: Define built-in webpack conditions using an enum and typescript union (#82765)

Turbopack: Define built-in webpack conditions using an enum and typescript union (#82765) ## Context We have some publicly documented syntax for configuring webpack loaders here: https://nextjs.org/docs/app/api-reference/config/next-config-js/turbopack#configuring-webpack-loaders However, we also have some undocumented features. Specifically, we have two different "condition" concepts, both of which are shown here: https://github.com/vercel/next.js/blob/1766a1aba6a7c92a03c08073114652d61da1a388/packages/next/src/build/swc/index.ts#L836-L860 1. The `conditions` field in the `turbopack` object of the config can be used to specify predicates (defined by file name glob, regex, or content of file) that can be referenced by rules. 2. There are special built-in internal "conditions" that can be matched by passing an object to a `rule` that does not contain a `loader` field. These special conditions allow us to match on some things we couldn't otherwise declare conditions for. This is about improving the current state of #2, which I'm calling here to "webpack loader built-in conditions". Confusingly, there are also very similar conditions used by the resolver context. I'm not changing those, but I've done a tiny bit of work in this PR to better clarify the difference with naming and types. ## This PR - Instead of using an `RcStr`, for these conditions, use an enum. Theoretically that gives us less flexibility, but it makes it way easier to discover, document, and keep track of what built-in conditions we support. I feel that it's very important that we do this because this enum is effectively a public API, and I'd like to document some version of this API in a subsequent PR. - Use the exact union of supported fields in the zod schema and typescript definitions. - Represent the collection of conditions as a set instead of a vec. In reality, this doesn't have much impact because the set is small and always constructed in the same order, but the intent is clearer. Implemented `TaskInput` for `BTreeSet`. - Some minor consistency cleanup between `next_server` and `next_client`. - Get rid of some extra type conversions using the `rcstr!()` macro.