Generated Files and Integration

Generated Files and Integration

Each generated module is a local npm/Yarn package inside the existing plugin:

existing-plugin/
├── package.json
├── android/
└── local_modules/
    └── local-math/
        ├── .supernote-module.json
        ├── README.md
        ├── package.json
        ├── index.js
        ├── index.d.ts
        ├── react-native.config.js
        └── android/

The generator adds a file: dependency to the parent package.json. React Native autolinking then discovers the local package through its generated metadata. This page describes only integration owned by the generator.

Backend-specific flow

Native

The Android build scans marked Kotlin/Java methods. Generated annotation processing, bridge, and registration expose them through a Promise-based Native module.

User-owned source:

android/src/main/java/<android-namespace>/

JNI

The build scans marked C++ functions. Generated bindings convert supported values, register JNI methods, load the library, and expose a Promise-based Native module.

User-owned source:

android/src/main/cpp/

JSI

Marked C++ functions become synchronous HostFunctions. Generated Kotlin loading and native installation attach those functions to the JavaScript runtime. The target PluginHost and device policy must permit that library to execute.

User-owned source:

android/src/main/cpp/

Ownership metadata

.supernote-module.json records:

• package identity and backend;
• generator and schema versions;
• generated_files that Update may replace;
• implementation_roots that Update preserves.

Do not customize this metadata by hand.

Generator-owned files

Update may replace:

• package metadata, wrapper, declarations, and generated README;
• React Native autolinking configuration;
• Gradle, CMake, manifest, annotation, and processor files;
• generated Kotlin/C++ bridge, loading, and registration files;
• the managed Native registration block in parent Android settings.

Keep implementation in the recorded user-owned roots. Keep project notes in the parent plugin because Update replaces the generated module README.

Transaction model

Add, Update, and Remove stage changes, journal affected paths, verify postconditions, and then activate the result. If complete rollback is not possible, exit code 3 and the retained journal describe the recovery action.

Transactions protect generator-managed changes; they do not replace version control. A successful Remove intentionally deletes the complete module, including user-owned implementation.

The maintenance rationale is recorded in ADR 0001.