next.js

d84e3bb5 - Use RcStr directly in napi(object) structs instead of converting to String (#92014)

Use RcStr directly in napi(object) structs instead of converting to String (#92014) ### What? Replace `String` fields in `#[napi(object)]` structs within `crates/next-napi-bindings/` with `RcStr`, and remove the corresponding unnecessary `.to_string()` / `.into_owned()` conversions at the NAPI boundary. Affected structs and fields: | File | Struct | Fields | |---|---|---| | `utils.rs` | `NapiIssue` | `file_path`, `documentation_link` | | `utils.rs` | `NapiAdditionalIssueSource` | `description` | | `utils.rs` | `NapiSource` | `ident`, `file_path` | | `utils.rs` | `NapiDiagnostic` | `category`, `name`, `payload` | | `project.rs` | `NapiRoute` | `pathname` | | `endpoint.rs` | `NapiAssetPath` | `path`, `content_hash` | ### Why? `RcStr` already implements `ToNapiValue` and `FromNapiValue` (behind the `napi` feature flag in `turbo-rcstr`, already enabled in `next-napi-bindings`). Despite this, many `#[napi(object)]` structs were still declared with `String` fields and converted from `RcStr` source data via `.to_string()` or `.into_owned()`, allocating a new heap `String` on every call just to hand it straight to the NAPI serializer. Since `RcStr` is reference-counted, using it directly avoids the allocation entirely — the refcount is simply incremented on clone and the underlying bytes are passed to `napi_create_string_utf8` directly. ### How? - Changed `String` → `RcStr` in the struct field declarations. - Updated the corresponding `From` / constructor impls to use `.clone()` instead of `.to_string()` / `.into_owned()` on `RcStr` values, and direct field moves where ownership is transferred. - Added `use turbo_rcstr::RcStr;` imports where not already present (`utils.rs`, `endpoint.rs`). `project.rs` already imported `RcStr`. - The JavaScript API surface is unchanged: both `String` and `RcStr` serialize to a JS `string` via the same underlying `napi_create_string_utf8` call. Co-authored-by: Tobias Koppers <sokra@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>