Skip to content

refactor(plugin): remove the unused flatDir injection - #14

Merged
IronTony merged 1 commit into
mainfrom
chore/plugin-remove-flatdir-injection
Sep 13, 2026
Merged

IronTony merged 1 commit into
mainfrom
chore/plugin-remove-flatdir-injection

Conversation

@IronTony

Copy link
Copy Markdown
Owner

Removes the config plugin step that injected a flatDir block into the consumer's root android/build.gradle. It had no effect, and on current Expo templates it never ran. This is the last change planned before publishing 2.0.0.

Why

  • The module's android/build.gradle has referenced the stripped sdk-pdf AAR by file path since 1.0.4 (implementation files("$projectDir/libs/sdk-pdf-2.1.7-stripped.aar")). That change was made because Gradle 9 stopped honoring subproject-scoped flatDir. Nothing reads a flatDir repository anymore.
  • The injection's regex allowed one level of braces inside allprojects. The Expo template's maven { url 'https://www.jitpack.io' } inside repositories is two levels, so on SDK 55 to 57 the block was never written and expo prebuild said nothing.
  • Kotlin Script projects got a warning with manual flatDir instructions they did not need.

Changes

  • plugin/src/index.ts: deletes withDocuSignAndroidStrippedAarFlatDir, FLAT_DIR_MARKER, the .kts warning and the call in withDocuSign. Two comments now describe the file-path reference instead.
  • plugin/src/index.test.ts: a new test asserts the only build.gradle change the plugin makes is the DocuSign repository line.
  • README.md: the Glide workaround section no longer says a flatDir injection picks up the AAR.
  • CHANGELOG.md: a 2.0.0 Fixes entry.

Verification

  • The new test fails with the flatDir mod registered and passes without it. It runs the real projectBuildGradle mod chain.
  • Plugin tsc, build, lint, examples type-check and all 101 Jest tests pass.
  • The package was packed from this branch and installed in an Expo SDK 57 app:
    • Prebuild produced a root build.gradle byte-identical to the previous package's output, with one DocuSign maven line and no flatDir block.
    • The Android release build passed checkReleaseDuplicateClasses.
  • Pre-push review returned SHIP on 2fd1e06. It found no remaining reader of a flatDir repository in android/, plugin/, scripts/, docs/ or the README, and confirmed git log -S dates the file-path reference to the 1.0.4 release commit.

Notes

  • Apps on a template where the old regex did match may still have the react-native-docusign-stripped-aar-flatdir block in a checked-in android/build.gradle. It stays inert and is safe to delete. expo prebuild --clean removes it.
  • Coverage for plugin/src/index.ts reads 43%, down from 49%, because the deleted mod was code the tests exercised. The untested part is the same as before: the AAR download, strip and cache paths.

withDocuSignAndroidStrippedAarFlatDir added an afterEvaluate flatDir block
to the root build.gradle so Gradle could find the stripped sdk-pdf AAR.
Since 1.0.4 the module's android/build.gradle references that AAR by file
path, because Gradle 9 stopped honoring subproject-scoped flatDir, so the
block had no effect. On current Expo templates it was never written either:
its pattern allowed one level of braces inside allprojects, and the
template's maven { url ... } entry inside repositories is two.

The mod, its marker, its Kotlin Script warning telling projects to add the
block by hand, and the comments describing it are gone. A new test pins the
plugin's only build.gradle change to the DocuSign repository line; it
failed while the flatDir mod was still registered.

In an Expo SDK 57 app, prebuild from the packed branch produced a
build.gradle byte-identical to the previous package's output and the
Android release build passed checkReleaseDuplicateClasses.
@IronTony IronTony self-assigned this Sep 13, 2026
@IronTony IronTony added the enhancement New feature or request label Sep 13, 2026
@IronTony
IronTony merged commit b062371 into main Sep 13, 2026
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant