Skip to content

chore(release): version packages - #497

Open
github-actions[bot] wants to merge 1 commit into
mainfrom
changeset-release/main
Open

github-actions[bot] wants to merge 1 commit into
mainfrom
changeset-release/main

Conversation

@github-actions

Copy link
Copy Markdown
Contributor

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

brownfield@6.0.1

Patch Changes

  • Updated dependencies [79817d1]:
    • @callstack/brownfield-cli@6.0.1

@callstack/brownfield-navigation@6.0.1

Patch Changes

  • Updated dependencies [79817d1]:
    • @callstack/brownfield-cli@6.0.1

@callstack/brownie@6.0.1

Patch Changes

  • Updated dependencies [79817d1]:
    • @callstack/brownfield-cli@6.0.1

@callstack/brownfield-cli@6.0.1

Patch Changes

  • #487 79817d1 Thanks @KisaneNeko! - Support Expo modules in React Native CLI apps. brownfield package:* no longer runs expo prebuild on projects with committed android/ and ios/ directories, which used to delete the brownfield library module. Prebuild now runs only when the native directory is missing or gitignored. If you commit the generated directories of an Expo app, run npx expo prebuild yourself after changing app.json or config plugins. create-react-native-brownfield now detects Expo and sets up the iOS framework to use the Expo runtime. On a re-run after adding Expo, it also raises an existing framework target to iOS 16.4.

    --use-prebuilt-expo now also turns Expo's precompiled modules on or off for pod install, and turns on Swift explicit modules so packaging works in projects that still carry the old SWIFT_ENABLE_EXPLICIT_MODULES = NO workaround. It defaults to building Expo from source when the app's React Native version doesn't match the one Expo's precompiled modules were built for.

    package:ios now copies the expo-image dependency XCFrameworks (SDWebImage and libavif) as real files instead of symlinks into node_modules, so the package works when moved to another machine.

    Re-running create-react-native-brownfield after pod install no longer adds a second Sources build phase to the framework target, which made the next pod install fail.

    The package:ios script that create-react-native-brownfield adds now passes --add-spm-package, so the iOS app adds one local Swift package instead of every XCFramework. Existing scripts aren't changed.

@callstack/create-react-native-brownfield@6.0.1

Patch Changes

  • #487 79817d1 Thanks @KisaneNeko! - Support Expo modules in React Native CLI apps. brownfield package:* no longer runs expo prebuild on projects with committed android/ and ios/ directories, which used to delete the brownfield library module. Prebuild now runs only when the native directory is missing or gitignored. If you commit the generated directories of an Expo app, run npx expo prebuild yourself after changing app.json or config plugins. create-react-native-brownfield now detects Expo and sets up the iOS framework to use the Expo runtime. On a re-run after adding Expo, it also raises an existing framework target to iOS 16.4.

    --use-prebuilt-expo now also turns Expo's precompiled modules on or off for pod install, and turns on Swift explicit modules so packaging works in projects that still carry the old SWIFT_ENABLE_EXPLICIT_MODULES = NO workaround. It defaults to building Expo from source when the app's React Native version doesn't match the one Expo's precompiled modules were built for.

    package:ios now copies the expo-image dependency XCFrameworks (SDWebImage and libavif) as real files instead of symlinks into node_modules, so the package works when moved to another machine.

    Re-running create-react-native-brownfield after pod install no longer adds a second Sources build phase to the framework target, which made the next pod install fail.

    The package:ios script that create-react-native-brownfield adds now passes --add-spm-package, so the iOS app adds one local Swift package instead of every XCFramework. Existing scripts aren't changed.

  • Updated dependencies [79817d1]:

    • @callstack/react-native-brownfield@6.0.1

@callstack/react-native-brownfield@6.0.1

Patch Changes

  • #487 79817d1 Thanks @KisaneNeko! - Support Expo modules in React Native CLI apps. brownfield package:* no longer runs expo prebuild on projects with committed android/ and ios/ directories, which used to delete the brownfield library module. Prebuild now runs only when the native directory is missing or gitignored. If you commit the generated directories of an Expo app, run npx expo prebuild yourself after changing app.json or config plugins. create-react-native-brownfield now detects Expo and sets up the iOS framework to use the Expo runtime. On a re-run after adding Expo, it also raises an existing framework target to iOS 16.4.

    --use-prebuilt-expo now also turns Expo's precompiled modules on or off for pod install, and turns on Swift explicit modules so packaging works in projects that still carry the old SWIFT_ENABLE_EXPLICIT_MODULES = NO workaround. It defaults to building Expo from source when the app's React Native version doesn't match the one Expo's precompiled modules were built for.

    package:ios now copies the expo-image dependency XCFrameworks (SDWebImage and libavif) as real files instead of symlinks into node_modules, so the package works when moved to another machine.

    Re-running create-react-native-brownfield after pod install no longer adds a second Sources build phase to the framework target, which made the next pod install fail.

    The package:ios script that create-react-native-brownfield adds now passes --add-spm-package, so the iOS app adds one local Swift package instead of every XCFramework. Existing scripts aren't changed.

  • Updated dependencies [79817d1]:

    • @callstack/brownfield-cli@6.0.1

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants