digidem / digidem/comapeo-core-react-native

CI: fast package-lint job (publint + attw + tarball-contents assertion)

Open
#88 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

ci priority: P1
Dominant language
Kotlin
Stars
1
Forks
0
Avg merge
8h 24m
Merged PRs (30d)
9

Description

Problem

The example app consumes the module via a Metro alias to the repo root (apps/example/metro.config.js@comapeo/core-react-native: '../..'), and all existing CI consumes the workspace source, never the packed tarball. Nothing today catches a missing files entry, an unbuilt native artifact, or a broken exports map — the classic "works locally, broken on npm" failure.

This module is especially exposed because most of what ships is generated and gitignored: android/src/main/jniLibs/**/*.so, android/src/main/assets/nodejs-project/, ios/Frameworks/**.xcframework, ios/nodejs-project/, android/libnode/, and build/. A regression in the files array or a platform-gated build step (e.g. publishing from Linux → empty ios/Frameworks/) would pass all current tests and produce a runtime-broken package.

Proposed: fast PR-level package-lint job

Cheap checks that run on every PR (seconds, reuse existing download:nodejs-mobile + backend:build steps on a macOS runner):

  • publint — validates exports/main/types resolution.
  • @arethetypeswrong/cli — catches ESM/CJS + types mismatches across the . and ./sentry export conditions.
  • Tarball-contents assertionnpm pack --json, then assert the tarball contains at least one android/src/main/jniLibs/**/*.so, one ios/Frameworks/**.xcframework, the Android + iOS nodejs-project bundles, android/libnode/bin/**/libnode.so, and build/index.js. This is the highest value-per-second check and would have caught a Linux-published (iOS-less) tarball.

Context

Spun off from the release workflow PR (.github/workflows/release.yml). See the build pipeline in scripts/build-backend.ts and the files array in package.json.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with .github/workflows/release.yml, scripts/build-backend.ts, and the files array in package.json; inspect how the existing download:nodejs-mobile and backend:build steps run on macOS. Add a fast PR-level package-lint job using the proposed package checks and tarball assertions, and verify it catches missing Android, iOS, nodejs-project, libnode, or build artifacts.

Written by the indexing model from the issue text.

Assessment

Tech stack
github-actions, typescript
Domain
build-system, ci-cd, release
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
68/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.