Closed NickGerleman closed 3 years ago
Looked closer at allowing versions prior to 0.64 to work with the template we provide with modules, and there are more tricky bits. Seems like bumping min target to 0.64 is the clean solution.
An alternate idea: Use 'react-native-test-app' so that it's easy to bump all the template apps at once, dependencies and all. That might help if we're going to bump the minimum from 0.61 to 0.64 and the other platform template apps break.
An alternate idea: Use 'react-native-test-app' so that it's easy to bump all the template apps at once, dependencies and all. That might help if we're going to bump the minimum from 0.61 to 0.64 and the other platform template apps break.
This could be a good idea in the future. For now I have a separate PR updating the example app: https://github.com/react-native-picker/picker/pull/308
I haven't used RNTA myself. How does it work for things like adding build logic to link in separate community modules?
@Naturalclar anything needed here?
:tada: This PR is included in version 2.0.0 :tada:
The release is available on:
Your semantic-release bot :package::rocket:
This updates the Picker module to match the currently provided module template. This means newer cppwinrt, ARM64 support, and a pathway for WinUI 3 support (coming in a future PR).
It is breaking though, as it will only correctly work with RNW 0.64+. This is arguable a bug in the current template, and I've filed https://github.com/microsoft/react-native-windows/issues/8459 to evaluate making our default template more compatible.
Reducing the matrix does make it easier to make the package WinUI 3 compatible though, so it is likely worth it here. I added an entry to the README compatibility table, to be filled when a new version is released.
Validated the separately updated example app functions the same as previously.