Hi team,
We're using react-native-audio-api (v0.13.1) with DISABLE_AUDIOAPI_FFMPEG=1 — we only use AudioRecorder and don't need any FFmpeg functionality.
Problem
The published npm tarball includes FFmpeg header files at common/cpp/audioapi/external/include_ffmpeg/ (131 .h files licensed under LGPL-2.1+). These are present in node_modules after npm install/yarn install regardless of whether the consumer has FFmpeg disabled.
This triggers license scanners in enterprise environments that flag the presence of LGPL-licensed files in the dependency tree. Even though the headers are never compiled or linked when FFmpeg is disabled (the preprocessor gates and build flags work correctly), their mere presence in the npm artifact causes compliance tooling to flag the package.
Current state
- The FFmpeg binaries are already correctly excluded from the npm tarball (downloaded at build time via the download script)
- The FFmpeg source files at
common/cpp/audioapi/libs/ffmpeg/ are excluded from compilation when disabled
- The FFmpeg headers at
common/cpp/audioapi/external/include_ffmpeg/ still ship in the npm artifact
Possible fix
Add common/cpp/audioapi/external/include_ffmpeg/ to .npmignore or exclude from the "files" field in package.json.
For consumers with FFmpeg enabled, the headers could be bundled with the prebuilt binaries download (similar to how .a/.so files are already handled) — the download script already runs at build time and could fetch a headers archive alongside the binaries.
Impact
- No breaking change for consumers with FFmpeg disabled (headers unused anyway)
- Consumers with FFmpeg enabled would get headers via the download script instead of the npm tarball
- Consistent with the existing approach for binary artifacts
- Resolves LGPL license scanner flags for enterprise consumers
Thanks!
Hi team,
We're using
react-native-audio-api(v0.13.1) withDISABLE_AUDIOAPI_FFMPEG=1— we only useAudioRecorderand don't need any FFmpeg functionality.Problem
The published npm tarball includes FFmpeg header files at
common/cpp/audioapi/external/include_ffmpeg/(131.hfiles licensed under LGPL-2.1+). These are present innode_modulesafternpm install/yarn installregardless of whether the consumer has FFmpeg disabled.This triggers license scanners in enterprise environments that flag the presence of LGPL-licensed files in the dependency tree. Even though the headers are never compiled or linked when FFmpeg is disabled (the preprocessor gates and build flags work correctly), their mere presence in the npm artifact causes compliance tooling to flag the package.
Current state
common/cpp/audioapi/libs/ffmpeg/are excluded from compilation when disabledcommon/cpp/audioapi/external/include_ffmpeg/still ship in the npm artifactPossible fix
Add
common/cpp/audioapi/external/include_ffmpeg/to.npmignoreor exclude from the"files"field inpackage.json.For consumers with FFmpeg enabled, the headers could be bundled with the prebuilt binaries download (similar to how
.a/.sofiles are already handled) — the download script already runs at build time and could fetch a headers archive alongside the binaries.Impact
Thanks!