Before opening, please confirm:
Amplify Hosting feature
Frontend builds
Is your feature request related to a problem? Please describe:
We've a pretty standard monorepo setup, where there's a few apps, and a few packages, specifically a ui subpackage that declares react components that the apps use. This was working perfectly until last night, when new components were added to the ui package, and used in the web app, but the build failed, stating that the new components weren't exported from the ui package.
A snippet of the logs made it even more confusing because,
...
2026-03-11T19:17:04.521Z [INFO]: @repo/ui:build: cache miss, executing 4e2813fd5dac0739
2026-03-11T19:17:04.522Z [INFO]: @repo/taxonomy:build: cache miss, executing a3958e2628705600
2026-03-11T19:17:09.241Z [INFO]: @repo/ui:build: Exports File Size
2026-03-11T19:17:09.247Z [INFO]: @repo/ui:build: . dist/es/index.js 1.49 kB
@repo/ui:build: dist/es/index.d.ts 1.55 kB
...
@repo/ui:build: ./svgs/baskeball-icon dist/es/svgs/basketball-icon.js 1.87 kB
it looked like the ui package was building correctly, with the new components that have just been added, but then, further in the build,
...
2026-03-11T19:17:18.748Z [INFO]: web:build: error during build:
web:build: src/components/SportCategoryIcon.tsx (2:23): "BasketballIcon" is not exported by "../../node_modules/@repo/ui/dist/es/index.js", imported by "src/components/SportCategoryIcon.tsx".
web:build: file: /codebuild/output/src3668123949/src/apps/web/src/components/SportCategoryIcon.tsx:2:23
web:build:
web:build: 2: import { BaseballIcon, BasketballIcon, FootballIcon } from "@repo/ui"
web:build: ^
web:build: 3: import type { FC } from "react"
This has since been solved this morning, by removing the standard caching instruction, that is specifically included in the monorepo docs - https://docs.aws.amazon.com/amplify/latest/userguide/monorepo-configuration.html
cache:
paths:
- node_modules/**/*
I can't be completely certain about what that instruction is exactly doing (the docs are quite sparse), but, for a monorepo, I, overall think, no subpackages that are built should ever be cached, at all. If your build is doing, as above, a "cache miss, executing" build, correctly, then that build should always be used, 100% of the time.
If that logic is too complex, then I think there should be a big warning about this situation in the monorepo docs, and better explanation of what the cache-path instruction is doing. A recommendation maybe would be to standardise your subpackages id's, like @repo/ above, and then use a monorepo-safe path, like node_modules/(!@repo)* (or something).
I can't be specific here, because I don't know exactly what path is, is it a standard glob match? I'm not sure, this goes back to my point about the docs again, again, there should be more information about cache and the cache paths.
Describe how you'd like this feature to work
The best solution would be to never cache a subpackage that's built during the build process, but at the very least a correctly working cache path for monorepos should be in the docs, with more details about the cache overall too.
Before opening, please confirm:
Amplify Hosting feature
Frontend builds
Is your feature request related to a problem? Please describe:
We've a pretty standard monorepo setup, where there's a few apps, and a few packages, specifically a ui subpackage that declares react components that the apps use. This was working perfectly until last night, when new components were added to the ui package, and used in the web app, but the build failed, stating that the new components weren't exported from the ui package.
A snippet of the logs made it even more confusing because,
it looked like the ui package was building correctly, with the new components that have just been added, but then, further in the build,
This has since been solved this morning, by removing the standard caching instruction, that is specifically included in the monorepo docs - https://docs.aws.amazon.com/amplify/latest/userguide/monorepo-configuration.html
I can't be completely certain about what that instruction is exactly doing (the docs are quite sparse), but, for a monorepo, I, overall think, no subpackages that are built should ever be cached, at all. If your build is doing, as above, a "cache miss, executing" build, correctly, then that build should always be used, 100% of the time.
If that logic is too complex, then I think there should be a big warning about this situation in the monorepo docs, and better explanation of what the cache-path instruction is doing. A recommendation maybe would be to standardise your subpackages id's, like
@repo/above, and then use a monorepo-safe path, likenode_modules/(!@repo)*(or something).I can't be specific here, because I don't know exactly what path is, is it a standard glob match? I'm not sure, this goes back to my point about the docs again, again, there should be more information about cache and the cache paths.
Describe how you'd like this feature to work
The best solution would be to never cache a subpackage that's built during the build process, but at the very least a correctly working cache path for monorepos should be in the docs, with more details about the cache overall too.