is it normal that touching one shared package rebuilds all 14 apps in ci Turborepo

Half right. Rebuilding everything downstream is correct and you do not want to change it - that is the whole point of the dependency graph and it is what stops you shipping a broken app because you changed a utility.

The part that is not normal is that it costs 22 minutes of wall clock every time. Two things fix that without giving up correctness:

1. Remote cache. If a package's inputs did not change, its build should be a download, not a build. When @acme/utils changes, everything downstream genuinely does need rebuilding, but on a PR that touches one app, the other 13 should cost a few seconds each. If they do not, your caching is broken and that is the actual bug.
2. Only test what is affected. Building everything downstream is cheap once cached. Running every test suite is not.

turbo run test --filter=...[origin/main]

runs tests for changed packages and everything that depends on them, and skips the rest. On a utils change that is still most of the repo, but on the 90% of PRs that touch one app it is a fraction.

The fact that people are avoiding the shared package is the real signal here. That is a build system problem turning into a code quality problem, and it always ends with three slightly-different copies of the same helper.

The other half is that @acme/utils is doing too much. A package that all 14 apps depend on is a package where every change is maximally expensive, so the pressure is to split it along the lines of who actually uses what.

When we did this - one utils became four smaller packages - the median blast radius of a change dropped from 14 apps to 3, without any build tooling changes at all. Cheapest performance work I have ever done.

Sign you need this: the package has no coherent one-sentence description. "Utils" is not a description, it is a place things go when nobody decided where they belong.

Worth internalising the distinction: "affected" is about the dependency graph, "changed" is about git. Most tooling gives you both and people conflate them. You want changed for deciding what to cache, affected for deciding what to verify.

The behavioural bit you noticed is the important part of the post. Once a directory becomes expensive to touch, people route around it, and the codebase quietly gets worse in ways no dashboard shows. I would raise it that way with your team rather than as a CI complaint - it lands better.

Six months in and asking whether the thing everyone accepts is actually correct. Keep doing that.