Turbopack Error: Failed to write app endpoint /elementCatogories/[slug]/page

[CoderSilicon]

Turbopack version: 23c46498
Next.js version: 16.1.6

Error message:

Failed to write app endpoint /elementCatogories/[slug]/page

Caused by:
- Next.js package not found

Debug info:
- Execution of Project::hmr_version_state failed
- Execution of Project::hmr_version failed
- Execution of VersionedContentMap::get failed
- Execution of VersionedContentMap::get_asset failed
- Execution of VersionedContentMap::compute_entry failed
- Execution of *emit_assets failed
- Execution of all_assets_from_entries_operation failed
- Execution of *all_assets_from_entries failed
- Execution of endpoint_output_assets_operation failed
- Execution of <AppEndpoint as Endpoint>::output failed
- Failed to write app endpoint /elementCatogories/[slug]/page
- Execution of AppEndpoint::output failed
- Execution of AppEndpoint::app_page_entry failed
- Execution of *get_app_page_entry failed
- Execution of AppProject::rsc_module_context failed
- Execution of *ModuleAssetContext::new failed
- Execution of *AppProject::get_rsc_transitions failed
- Execution of AppProject::ecmascript_client_reference_transition failed
- Execution of *NextEcmascriptClientReferenceTransition::new failed
- Execution of AppProject::ssr_transition failed
- Execution of *FullContextTransition::new failed
- Execution of AppProject::ssr_module_context failed
- Execution of AppProject::shared_transition failed
- Execution of *FullContextTransition::new failed
- Execution of AppProject::shared_module_context failed
- Execution of *ModuleAssetContext::new failed
- Execution of get_server_resolve_options_context failed
- Execution of get_next_server_import_map failed
- Next.js package not found

[MILLERMARRU]

"Next.js package not found" comes from try_get_next_package in next-core's import map setup (crates/next-core/src/next_import_map.rs):

pub async fn try_get_next_package(context_directory: FileSystemPath) -> Result<Vc<OptionFileSystemPath>> {
    let root = context_directory.root().owned().await?;
    let result = resolve(
        context_directory.clone(),
        ReferenceType::CommonJs(CommonJsReferenceSubType::Undefined),
        Request::parse(Pattern::Constant(rcstr!("next/package.json"))),
        node_cjs_resolve_options(root.clone()),
    );
    ...
}

This is Turbopack's own Rust-side resolver doing a standard Node CommonJS resolution for next/package.json, starting from context_directory and walking up looking for it in node_modules, the same algorithm Node's own require.resolve uses. Your trace shows it failing specifically while setting up the RSC/SSR shared module context (AppProject::shared_module_context → get_next_server_import_map → get_server_resolve_options_context), so it's not a generic startup check, it's genuinely unable to find next reachable from that specific resolution context.

That points at the package manager's node_modules layout rather than a Turbopack regression, most commonly:

• A pnpm workspace where next isn't hoisted to a location visible from the directory Turbopack is resolving from (strict, non-flat node_modules by design), especially if the page/route in question lives in a sub-package.
• A partial or interrupted install, worth confirming node_modules/next/package.json actually exists on disk and isn't a dangling symlink.
• If this is a monorepo, whether next is declared as a dependency of the specific workspace package containing the route that's failing, not just the repo root.

Since this is happening on a specific route (/elementCatogories/[slug]/page), if the issue is in fact hoisting-related, other routes in the same project resolving fine while this one fails would be a useful data point, since context_directory should differ based on where the failing endpoint's compilation is actually rooted.

[CoderSilicon]

Only this specific route was failing, rest was fine. Although it was resolved when the packages were reinstalled. But it may occur again.