Auto-linking for native modules (source-based) #5044
Conversation
* Updated `npx react-native config` to create the needed json for auto-linking * New `npx react-native autolink-windows` command to perform auto-linking * Auto-linking occurs automatically during `npx react-native run-windows` * New Auto-linking targets and props so CLI apps throw a warning if auto-linking should be run * New targets and props for native modules to consume Closes microsoft#2853
vnext/PropertySheets/External/Microsoft.ReactNative.Uwp.CSharpModule.props
Outdated
Show resolved
Hide resolved
vnext/PropertySheets/External/Microsoft.ReactNative.Uwp.CSharpModule.targets
Outdated
Show resolved
Hide resolved
vnext/local-cli/generator-windows/templates/cpp/src/AutolinkedNativeModules.g.h
Outdated
Show resolved
Hide resolved
|
I mentioned this somewhere else, but we should really consider moving local CLI code to typescript with implicit any sooner than later. Types can be incrementally added, and we get way better readability, dev experience, the ability to use ES6 import and export, etc. |
|
There has been a lot of recent conversation about how we need better test coverage. Any ideas on how we might be able to build validation for this change? |
The current CI will already capture the case of a CLI app where there are no community modules installed. Autolinking will run, and everything should still work. At some point we'll want a CI task that creates a new app, adds a community module, builds and verifies that autolinking worked. However to do that we need to get this in, and backported into a release, and get a community module that is willing/able to upgrade to the RN version we've backported to, then make sure the windows implementation is upgraded and working too. In that respect I'm working on a PR for react-native-camera, getting it to build against 0.62, but they are built on RN 0.59, and I'm not sure yet how to make the windows implementation build on both 0.62 and anything earlier, since 0.62 changed a lot build-wise. |
vnext/local-cli/generator-windows/templates/cpp/src/AutolinkedNativeModules.g.targets
Show resolved
Hide resolved
asklar
left a comment
asklar
left a comment
There was a problem hiding this comment.
Mainly I want to make sure we have the right docs to make it clear for folks how this works. My feedback, prioritized:
P1: Make sure we have a good doc on this explaining behavior and fallbacks.
P2: Don't rely on side effects of using the app targets Import in order to infer which one is the app project, just use an actual property on the project and use that.
P2: Ideally we don't use our own regex based matching for parsing XML and we instead use something like xml2js or node-xml
P2/P3: other minor feedback
ghost
added
Needs: Author Feedback
|
I can't check-in the docs until the 0.62 releases and the website version is bumped. Here's the PR: microsoft/react-native-windows-samples#145 Here are the relevant docs: |
| <AutolinkCommand Condition="'$(AutolinkCommand)' == ''">npx react-native autolink-windows</AutolinkCommand> | ||
| <AutolinkCommandArgs Condition="'$(AutolinkCommandArgs)' == ''">--check</AutolinkCommandArgs> | ||
| <AutolinkCommandWorkingDir Condition="'$(AutolinkCommandWorkingDir)' == ''">$([MSBuild]::GetDirectoryNameOfFileAbove($(ProjectDir), 'package.json'))</AutolinkCommandWorkingDir> | ||
| <AutolinkCommandArgs Condition="'$(AutolinkCommandArgs)' == '' And '$(SolutionPath)' != '' And '$(ProjectPath)' != ''">--check --sln $([MSBuild]::MakeRelative($(AutolinkCommandWorkingDir), $(SolutionPath))) --proj $([MSBuild]::MakeRelative($(AutolinkCommandWorkingDir), $(ProjectPath)))</AutolinkCommandArgs> |
There was a problem hiding this comment.
who's setting SolutionPath and ProjectPath?
There was a problem hiding this comment.
I added this as an extra safeguard to make sure the check runs accurately for playground (and potential other multi-solution or multi-app project setups). It's conditional on SolutionPath and ProjectPath existing. Otherwise, it falls through to the default args which is to just use the result from react-native config.
Alternatively I could just override the args prop in playground projects, but I didn't want to make such a change in the template for all apps.
I know running msbuild directly against a project doesn't set the solution path. But using VS or run-windows, it gets set.
There was a problem hiding this comment.
I'm not 100% happy with it, as we should be relying entirely on react-native config, but this was the best compromise I could come up with for multi solution setups.
There was a problem hiding this comment.
@jonthysell thanks for the explanation. I can't find how it gets set through run-windows though (I assume VS has its own way of invoking msbuild which sets these variables up), but since we're invoking msbuild manually I would have expected us to pass /p:... or something like that
* Added docs for autolinking added in RNW 0.63. See microsoft/react-native-windows#5044 * Fixed unbroken errors
* Added docs for autolinking added in RNW 0.63. See microsoft/react-native-windows#5044 * Fixed unbroken errors
5 participants
npx react-native configto create the needed json for auto-linkingnpx react-native autolink-windowscommand to perform auto-linkingnpx react-native run-windowsrun-windows --no-autolink) throw a warning that auto-linking should be runrun-windowsworksrun-windowsto properly consume react-native configCloses #2853
Microsoft Reviewers: Open in CodeFlow