Migrate to npm and publish via the shared release workflow

[JStonevalley]

Why

The shared publish pipeline in sellpy/package-release-actions has been adopted by pdf-creator, commons, automation-commons and fetch-graphql-schema (automation-commons#16 most recently), all four with real releases through it. This repo is the fifth and last single-package one; after it only design-system remains.

It was also the furthest from the others: the only one publishing on: release rather than on a labelled merge, and the only one on Yarn. The registry becomes the source of truth for the released version, and nothing is pushed to main any more — only a vX.Y.Z tag.

What is here

release.yml becomes a caller stanza, keeping the trigger, concurrency group, validate gate and NPM_AUTOMATION_TOKEN secret name here, which is what the shared workflow leaves to callers. permissions: contents: write on the calling job is required, not optional — a called workflow can lower the permissions it is handed but never raise them. The hand-written ~/.npmrc, the vestigial yarn pack step and --access public go with it.

ci.yml gains workflow_call so the publish can gate on it, and pr-validation.yml is new.

package.json takes a 0.0.0-managed placeholder and drops publishConfig.registry, which outranks the --registry flag the shared workflow publishes with. publishConfig.access: "public" replaces the old --access public flag; the package is already public on npmjs, so this records intent rather than changing anything.

Setup and CI move to npm ci with setup-node's npm cache, and checkout/setup-node go from v3 to v5 (v3 runs on the retired Node 16 runner). CONTRIBUTING.md is rewritten for npm and documents the new release cadence: every merge to main now publishes, and a semver label is mandatory on every PR.

Unique to this repo

This is a Yarn 3 → npm migration as well as a pipeline one, since the shared workflow installs with npm ci. Three things in it would each have broken the release on their own:

react-native-builder-bob cannot find tsc under npm ≥ 9. bob 0.20 locates it by running npm bin, removed in npm 9, then falls back to which tsc with only a warning — so it silently uses a global TypeScript locally and fails hard on a runner that has none. Pinned via bob's tsc option.

npm's hoisting broke the example. Yarn's nmHoistingLimits: workspaces kept expo and the peer deps in example/node_modules; npm hoists them to the root, which breaks the relative import App from '../../App' inside expo/AppEntry.js and leaves the metro aliases pointing at paths that no longer exist. The example now registers its root component from its own index.js and resolves peer deps with require.resolve.

The example moves to Expo 54 and Metro web bundling. expo export:web and @expo/webpack-config were deprecated in SDK 50 and webpack removed in SDK 51, so upgrading that package would only have bought time. webpack.config.js, @expo/webpack-config and babel-loader are deleted and CI runs expo export -p web. Expo 54 brings react 19.1.0, react-native 0.81.5, react-native-web ~0.21.0 and friends, with the root's react/react-native devDependencies tracking the same versions; babel-preset-expo and @react-native/babel-preset become explicit dependencies because they no longer resolve transitively.

Three consequences of that upgrade worth flagging:

• .nvmrc v18 → v22. RN 0.81 requires Node ≥ 20.19, so v18 fails at install. The shared workflow reads .nvmrc, so releases build on 22 from now on — same as the siblings.
• A public type widened. React 19 made useRef<T>(null) return RefObject<T | null>, which RefObject<NativeComponent> and RefObject<ScrollView> no longer accept, so bob build failed emitting definitions. Those parameters now take | null. Internal dereferences already null-checked, so no logic changed, and widening leaves existing callers unaffected.
• Lint was fully broken until @react-native/eslint-config@0.81 turned out to have dropped eslint-plugin-prettier, leaving prettier/prettier unregistered. The config now extends plugin:prettier/recommended.

Testing

The registry read, publish and tag push only run on a merge, so they cannot be verified beforehand — but four sibling repos have released through this exact workflow.

On the first merge, expect Registry latest is 0.1.1, publishing 0.1.2 (patch), then a publish, then tag v0.1.2.

Two gaps to know about: the native dev flow (start/ios/android) has not been run — it needs a device, and the entry point, dependency resolution and Expo major all changed, so start the app once before merging. And the jest suite is a single test.todo, so needs: validate gates lint, typecheck and builds rather than real coverage.

[JStonevalley]

@ThunbergOlle will migrate this into Sellphone