#Nuxt Layers + Modules Dependency issue

1 messages · Page 1 of 1 (latest)

orchid oasisBOT
#

Hi @dim knot. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:

#

Nuxt’s docs don’t explicitly describe your exact @nuxt/ui + remote GitHub layer scenario, so I can’t say with certainty how nuxt prepare is resolving that dependency. But there are a few relevant points about layers and dependencies:

  1. Remote layers’ dependencies live in their own node_modules
    When you extend a remote Git repo as a layer, Nuxt uses c12/giget and installs that layer (and its dependencies) into a special location under your project’s node_modules/.c12/.... Those dependencies are not automatically available to your main app’s package manager. [Publishing layers]

  2. Docs recommendation for npm‑published layers
    When publishing a layer as an npm package, Nuxt recommends putting anything the layer imports into that package’s dependencies, and then installing that package in the consuming project. [Publishing layers]
    That pattern assumes the consuming project has the layer package installed as a dependency/devDependency, so its dependencies are resolvable during Nuxt’s lifecycle.

  3. Module loading order vs. resolution
    Nuxt guarantees that layer modules run before project modules, and project modules have higher priority. [Corrected module loading order]
    But this is about execution order, not about how Node resolves @nuxt/ui when nuxt prepare runs.

Given this, the safest and most “Nuxt‑aligned” pattern today is:

#
  • The layer’s package.json should list @nuxt/ui in its dependencies.
  • The consuming app should install the layer itself as a dependency (npm package or git dependency). [Publishing layers]

For remote Git layers specifically, the docs also warn that dependencies of the remote layer are not generally usable “outside of Nuxt” because they live under .c12. [Publishing layers] That suggests that if Nuxt’s own tooling (like nuxt prepare during npm install) cannot resolve @nuxt/ui from that special location, you may indeed need to:

  • Also install @nuxt/ui in the main app so that nuxt prepare can resolve it from the project’s node_modules.

So, to your concrete questions, based only on the docs:

  • The docs do not clearly state that “having the dependency only in the base layer is sufficient” for remote Git layers.
  • The docs do imply that for reusable layers, the recommended pattern is to publish them as npm packages and install that package (with its dependencies) in the consuming app. [Publishing layers]

Given your error only appears during npm install / nuxt prepare, the most reliable fix consistent with the docs is:

  • Either publish/use the base layer as an npm package and install it in main-app, or
  • Keep using the Git layer but also add @nuxt/ui as a dependency in main-app so Nuxt can resolve it during prepare.

If you want to avoid duplicating dependencies, the npm‑package approach for the base layer is the pattern Nuxt documents explicitly.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@dim knot Kapa.ai is still learning and improving, please let me know how I did by reacting below.

dim knot
#

@orchid oasis I did some changes to my Nuxt layers app (base-app). creating a new component and updating styles. but when trying to use it via extends: [
['gh:Autoo-ma/autoo-base-app#main', { auth: process.env.GIGITHUB_TOKEN, install: true }]
],
I can't access to the new component (Failed to resolve component)

orchid oasisBOT
#

Let me check the knowledge base for you again. One moment! :books:

#

The knowledge sources don't contain specific information about component resolution failures with remote GitHub layers, so I can only share what the docs do say that's relevant to your situation.

Most likely cause: cached layer from a previous clone

When you use github: (or gh:) as a layer source, Nuxt uses giget to clone the repo into a local cache (under node_modules/.c12/). If the cache isn't invalidated, your new component won't be picked up even after you push changes to main.

What to try:

  1. Delete the cached layer — remove the cached clone so Nuxt re-fetches it:

    rm -rf node_modules/.c12

    Then re-run npm install / nuxt prepare.

  2. Pin to a specific tag or commit instead of #main, so you can be sure you're pulling the exact version you expect:

    export default defineNuxtConfig({
  extends: [
    ['github:Autoo-ma/autoo-base-app#v1.0.1', { auth: process.env.GIGITHUB_TOKEN, install: true }]
  ]
})

    [Publishing layers]

  3. Verify the component is in the correct directory — in Nuxt 4, layer components must be under app/components/* (not just components/*) to be auto-scanned. [Authoring Nuxt Layers]

  4. Avoid ~/ aliases inside the layer — if your new component imports assets or other files using ~/, those aliases resolve relative to the consuming project, not the layer, which can cause resolution failures. Use relative paths inside the layer instead. [Relative Paths and Aliases]

#

Beyond these points, the knowledge sources don't provide more detail on remote layer caching behavior, so I'd recommend also checking the Nuxt GitHub issues for similar reports.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@dim knot Kapa.ai is still learning and improving, please let me know how I did by reacting below.

dim knot
#

@orchid oasis I have removed the .c12 and reinstall the packages. but still it's not get the latest commit from github repo

orchid oasisBOT
#

Let me check the knowledge base for you again. One moment! :books:

#

The knowledge sources don't contain specific information about how Nuxt/giget handles cache invalidation or forces a fresh fetch from a remote GitHub layer source, so I can't give you a fully evidence-based answer on the internals of that caching mechanism.

What the docs do say is relevant here:

  • Nuxt uses unjs/giget to fetch remote git sources. [Going Deeper] The caching and fetching behavior is ultimately controlled by giget, not Nuxt itself — so for detailed cache behavior, the giget and c12 documentation would be the authoritative source.

Practical suggestions based on what the docs support:

  1. Pin to a specific commit SHA or tag instead of #main. Using a branch name like #main may cause giget to serve a cached version. Pinning to a specific tag or commit hash forces it to fetch a distinct version:

    export default defineNuxtConfig({
  extends: [
    ['github:Autoo-ma/autoo-base-app#v1.0.2', { auth: process.env.GIGITHUB_TOKEN, install: true }]
  ]
})

    [Publishing layers]

  2. Consider publishing the base layer as an npm package instead of using a raw GitHub source. The docs explicitly recommend this pattern for reusable layers, and it gives you proper versioning and reliable dependency resolution. [Publishing layers]

#

Beyond these points, the knowledge sources don't provide enough detail to diagnose why giget isn't picking up the latest commit after clearing .c12. I'd recommend checking the unjs/giget GitHub repo directly for cache-related issues or options.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: