aws-amplify / aws-amplify/amplify-hosting

Monorepo subpackage isn't updated when using documented cache path

Open
#4,084 2 comments 0 reactions 0 assignees View on GitHub
feature-request
Dominant language
Dockerfile
Stars
481
Forks
123
PR merge metrics
No merged PRs in 30d

Description

### Before opening, please confirm:

- [x] I have checked to see if my question is addressed in the [FAQ](https://github.com/aws-amplify/amplify-hosting/blob/master/FAQ.md).
- [x] I have [searched for duplicate or closed issues](https://github.com/aws-amplify/amplify-hosting/issues?q=is%3Aissue+).
- [x] I have removed any sensitive information from my code snippets and submission.

### 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.

Contributor guide

Open the contributing guide

Research direction

Start by reading the monorepo configuration documentation linked in the issue, focusing on the node_modules cache-path example and its interaction with frontend builds. Verify what the cache path does for the built @repo/ui package, then update the documentation so the cache behavior, path syntax, and monorepo-safe guidance are explicit; done means the documented setup does not leave stale subpackage output unexplained.

Written by the indexing model from the issue text.

Assessment

Tech stack
react, typescript
Domain
build-system, ci-cd, documentation
Issue type
Documentation
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.