fix: stop publishing the package's Babel config to consumers

[PsukheDelos]

Problem

package.json carries a babel key:

"babel": {
  "presets": ["@babel/preset-env", "@babel/preset-react"],
  "plugins": ["@babel/plugin-proposal-class-properties", "@babel/plugin-transform-runtime"]
}

That config exists purely to compile this repo's own src/ for jest -i. It has no purpose for consumers — the package publishes untranspiled source ("main": "src/index.js"), so consumers compile it with their own Babel setup.

But package.json is always included in the npm tarball, so this file-relative Babel config ships to every install and lands at node_modules/react-native-nfc-manager/package.json, where consumer tooling can pick it up. In Expo/EAS builds it collides with babel-preset-expo and the build fails with a Babel config conflict.

Downstream projects are currently working around this with patch-package — stripping the babel key from the installed package.json. We've been carrying such a patch for a while, and it seemed better to fix it at the source than to keep re-cutting the patch on every release.

Fix

Move the config verbatim into babel.config.js.

babel.config.js isn't in the files whitelist, so it's never published — confirmed with npm pack --dry-run:

file	before	after
package.json (with babel key)	shipped	shipped, no babel key
babel.config.js	—	not shipped

Presets and plugins are unchanged, so the local build/test behaviour is identical. babel.config.js is a root config rather than a file-relative one, which is the correct form for "compile this project" and is what babel-jest resolves from the repo root.

Verification

Run against main before and after:

• npx jest -i — 3 suites, 20 tests, passing both before and after.
• npx eslint . — clean.
• npm pack --dry-run — babel.config.js absent from the tarball, as above.

Note (not included here)

@babel/plugin-proposal-class-properties has been deprecated in favour of @babel/plugin-transform-class-properties since Babel 7.22, and @babel/preset-env has bundled the class-fields transform since 7.14 — so the explicit plugin is likely redundant now. I left it alone deliberately: renaming or dropping it means regenerating package-lock.json, and against a lockfile this age that produces a few hundred lines of unrelated transitive drift. Happy to send that as a separate PR if you'd like it.