skip to content

After includeFlat('shared'), how do you reference that project as a dependency from another module, and does its sibling directory location change the dependency syntax?

level: juniorimportance: should knowfreq 18%

answer

  1. depend by project path :shared
  2. directory location irrelevant to dep syntax
  3. type-safe accessor projects.shared
  4. path comes from registration, not disk
  5. refactor layout without touching consumers

basics

~10 s

You reference it by its project path, project(':shared'), exactly like any included project. The sibling directory on disk does not change the dependency syntax — only its projectDir differs.

solid answer

~40 s

Once `includeFlat('shared')` registers the project, it has the logical path `:shared` — a direct child of the root, identical in form to an `include`d project. So from a consumer module you declare the dependency the normal way: `implementation(project(":shared"))`. The fact that `shared` physically lives in `../shared` is invisible at the dependency level; Gradle's project dependency uses the **project path**, not the directory. This is a direct consequence of `includeFlat` only changing `projectDir`, not the project model. If you used type-safe project accessors, it would surface as `projects.shared`. Nothing about cross-project dependency resolution, configuration variants, or task wiring changes because of the flat layout.

code

kotlin · 7 lines
kotlin
// settings.gradle.kts
includeFlat("shared")

// consumer/build.gradle.kts
dependencies {
    implementation(project(":shared"))   // or: implementation(projects.shared)
}

go deeper

for a junior

Know you depend on it via project(':shared') like any subproject.

for a middle

Explain that the dependency uses the project path, so the sibling directory is invisible to consumers.

for a senior

Note that refactoring include<->includeFlat needs no consumer changes if the path is stable, and how variant resolution is path-keyed.

for a principal

Standardize stable project paths so directory-layout changes never ripple into dependency declarations across teams.

## Project path is the handle In Gradle, you depend on another subproject by its **project path**, written `project(":path")`. The path comes from how the project was registered in settings, not from where its files live. `includeFlat('shared')` registers `:shared` as a top-level child of root, so: ```kotlin dependencies { implementation(project(":shared")) } ``` works exactly as if `shared` were a normal subdirectory. The `../shared` location is purely a `projectDir` detail handled inside settings. ## Type-safe project accessors With type-safe accessors enabled (default in modern Gradle for the build's projects), the same dependency is: ```kotlin dependencies { implementation(projects.shared) } ``` The accessor name is derived from the project path (`:shared` -> `projects.shared`), again independent of the directory. ## Why the directory is irrelevant here Project dependencies resolve through the build's project graph and the target's outgoing variants (e.g. its `apiElements`/`runtimeElements` configurations), keyed by project path. The filesystem location only matters when Gradle reads that project's `build.gradle.kts` and sources — it doesn't leak into how consumers name it. ## Practical implication You can refactor a project from `include` to `includeFlat` (or vice versa) by moving its directory and changing one line in settings, **without touching any consumer's dependency declarations**, as long as the project path stays the same. ```kotlin // consumer/build.gradle.kts — unchanged regardless of flat vs nested layout dependencies { implementation(project(":shared")) } ```

  • If you move :shared from a subdirectory to a sibling (include -> includeFlat), must consumers change?
    No. As long as the project path :shared is unchanged, consumer dependency declarations stay the same; only settings changes.
  • What is the type-safe accessor for an includeFlat('shared') project?
    projects.shared, derived from the project path :shared, not from its directory.

saying these in an interview costs you the question

  • Thinking you must reference the project by a relative path like project('../shared').
  • Believing the flat layout requires special dependency syntax.
  • Confusing project path with projectDir.

context

resolving links…