This starts to clean up our repo when using a package manager (`midgard-yarn-strict` in this case) which forces dependency correctness. It gets us to the point where we are able to run the setup phase successfully.
There are a couple of quick tsconfig fixes as well that I ran across (namely around `esModuleInterop` duplication after we enabled it by default). Other discovered fixes were split into different PRs.
This also makes our Setup phase a little faster since we can do a scoped yarn install (mitigating extra cost of the isolated node_modules structure).
Co-authored-by: Jon Thysell (JAUNTY) <jthysell@microsoft.com>
## Description
This PR adds certain values of important MSBuild properties to the telemetry of `run-windows`.
### Type of Change
- New feature (non-breaking change which adds functionality)
### Why
There are some key MSBuild properties that would make it easier for us to debug and troubleshoot build problems if we knew their values.
Resolves#9165
### What
A new OutputMSBuildProperties.targets file to run before Build, which outputs the properties we want to capture to a JSON file, to be consumed by run-windows and reported. We set up a callback to load this file at the end of the command.
Also, this PR contains Eval-MsBuildProperties.ps1 script which loads the Microsoft.Build.dll and uses it to correctly process the build tree and get the correct value of specified properties. It's slow but should work even if the build fails. There is a new wrapper method in msbuildtools to call the script, though we're not using it anywhere yet, because it takes ~16s to run.
## Testing
Verified that the new properties get pushed into the telemetry with a local Fiddler proxy server.
* Add beachball change transformer
Beachball has a relatively recent option, which allows modifying changefiles before trying to bump/publish. We can use this to workaround two common painpoints.
1. Changes backported to 0.69 and later will not need any modification to changefiles when cherry-picking.
2. We do some formatting to create consistency of omiting the version in change messages in our changelogs
* Remove stale file
* Change files
* Fix bug around missing packages
* Fuller JS env in setup
* Simplify logic
* Fix template path
* use remote midgard-yarn on ubuntu agent
* yaml
* Build more
* Move beachball config to its own package
* Consistency
* Cleanup yarn install logic for hosted vs managed images
* Fixup lockfile issues
* Update min to node 14
* Import shared variables and rename
* Variable fixup
* Stamp RNW Version into MSBuild Props
This change allows community modules to query against the RNW version used at compile-time. This creates a foundation for conditional compilation against new features/APIs/quirks.
In order to calculate the new version number, existing DLL stamping code is run after the NPM package is published. Because we want to insert the version into the NPM package, we need to hook-in earlier. We use beachball prePublish hook as a mechanism to do this,. For clarity, we also commit the generated version to the repo, alongside the change to update package.json.
Using beachball hooks requires us moving our root beachball config from our packge.json to a JS file. We previously mutated beachball args in the package.json, so we need to rewrite some of the code which generates beachball config.
Props source of truth is a generated PropertySheet, exposed to internal and external projects. Preprocessor definitions mirroring the props are exposed by default to C++ apps/libs via external property sheets in the npm package.
Stamping is done via a JS script and mustache templates (ala generator). This should make it easy to stamp versions into more file formats in the future (E.g. for runtime queries in C++/C#).
* ordering
* Add macros
* Update beachball.config.js
* yarn format
* fiz
* Update vnext/template/cpp-lib/src/pch.h
* formatting and git
* fix comparison
* Use existing commit message for familiarity
* Update TypeScript in package.json
* parens and subsequent `yarn format`
* inverted quotes
* @react-native-windows/automation
This combines and documents some packages to allow external applications to leverage the work we did to allow UI testing. The various READMEs in this PR lay out what the user-flow and architecture looks like, but there is still some work around extracting IPC/tree dumping to be externally usable.
* Change files
* declare missing dependency
* Defer browser usage until after client require
* Workaround transform bug
* Rename node-rnw-rpc to @react-native-windows/automation-channel
The node-rnw-rpc package is used to enable test runners to interact with an RNW application, and is used in e2e-test-app and integration-test-app. It enables scnearios, such as sending the XAML tree over the wire to Jest.
There has been some interest in using this external to the RNW repo. This rename prepares for moving some of the common automation infra in the test apps to the native module that may be shared.
* 0.0.0 before 0.0.1
* Change files
* 0.0.0
* More renaming
* yarn format
* Add repository info
* Another rename
* More renaming
* Build Fixes
* fix casing
* Rename override-tools to react-native-windows-override
Fixes#4859
This chnage:
1. Matches better with other packages
2. Allows unambiguously mapping bin name to package name, allowing us to reccomend npx usage instead of Yarn, which has odd cwd behavior.
We also need to update out gitignore file which no longer was allowing checking in VS Code project settings.
* Use public react-native-platform-override instead of react-native-windows-override
* Update descriptions, reduce some hardcoding
* Remove some more duplication
* Missing file
* Remove require-time dependency to be called from the package bin. I.e. allow scripts to still work
* More path hardening
* Simplify logic a bit more
* Fic string
* add preprocess target to M.RN and missing deploy target in playground
* dont overwrite msbuild log when deploying
* Change files
* add *.pp to gitignore
Improve/refactor e2etest and TreeDumpLibrary in a number of ways:
most importantly is that we've had test break but not fail the PR or CI - this is because wdio which we use as a test harness, does not set its exit code on success/failure, which is needed for Azure Pipelines to know whether it should fail the build or not.
image
Because we were blind to test failures, the outputs have drifted away from the original masters. I'm re-baselining them based on what we have today. Component owners should do a pass on the new masters to make sure nothing looks weird (e.g. ImageRTL still shows FlowDirection=LeftToRight). Filed #4589 to track this.
changes the test app UI to provide links to the master and output files, and to diff the two. I wanted to launch vscode in diff mode for that but since we are a UWP app, the only way we can launch a program like that is to use a protocol handler, which vscode doesn't expose for diffing. Filed: Provide a protocol handler for diffing two files. For the time being, we'll copy the command line to launch vscode in diff mode for the two files.
Adds the ability for the tree dump library to output json which will allow us to write tests that validate the output from the javascript side
Adds logic for optionally output the name of elements. I plan to turn this and json output on soon but wanted to get a baseline PR/CI first.
e2etest was crashing because of a bug in Switch: #4596 . Disabled that control in the test app for the time being.
Added logic to the pipeline to capture crash dumps when e2etest app crashes
Added checks to make sure we don't try to build/run the e2etest app in scenarios where it isn't really supported because the masters would not match (anything other than Release|x64 at 100% DPI). There are bugs tracking these limitations that we must fix before rtm: #4122 and #4619
-Surface msbuild errors (shows as undefined right now)
-downloading nuget with Invoke-WebRequest will usually take a long time because of the PS progress bar (which sadly gets updated for every byte), so I'm disabling the progress bar (it only takes a second to download when the progress bar is turned off)
retry once if nuget failed since if you cancel at just the right time, you could end up with a truncated nuget.exe and are wedged unless you know which file to delete. Learned that the hard way.
-factor out calling onto powershell functions
-we were not exposing whether the function failed or not
* Add yarn workspace and an additional package -- and start hooking up beachball
* update lock
* Dont allow patch changes on react-native-windows
* Change files
* Fix publish pipeline to work with beachball
* UWP build needs to run yarn from root.
* Simplify our custom rn-cli.config
* Hook up some basic formatting configuration for vscode
* Replace tslint with eslint
* Format on save
* Fix a bunch of eslint errors
* Dont run lint on already build files
* lint now enforces LF to match community
Updating the NuGet package fixes some issues with the dispatcher execution context in the background. In Microsoft.NETCore.UWP 5.x.x, the Dispatcher for the MainView had no execution context, so asynchronous methods would not return on the dispatcher thread.
* Fixed ChakraCore DLL copy for bundle builds - removed some unneeded <prefer32bit> tags on 64 bit configurations - added bundle content group
* Adding winium test for playground.Net46
* Fixing debug x86 build error
* Adding npm i to appveyor to pick up jasmine
* The NMock3 library is not compatiable with Universal Windows Projects... Any TestFixtures that utilize the NMock3 library need to be isolated in the .NET test project(s)...
Moved NMock3 related tests from ReactiveNative.Shared.Tests to ReactNative46.Tests.
The majority of tests in JavaScriptModuleBaseTests.cs utilized NMock so the entire file was moved from the ReactiveNative.Shared.Tests to the ReactNative.Net46.Tests projects.
A handful of tests in JavaScriptModuleRegistryTests.cs utilized NMock. A specialized class inheriting from JavaScriptModuleRegistryTests was added to the ReactNative.Net46.Tests project. The specialized class "JavaScriptModuleRegistryNMockTests" contains only the NMock dependent tests and the base class contains all tests that can be shared.
All references to NMock have been removed from the test code in the ReactNative.Shared.Tests projects...
A reference to the ReactNative.Shared.Tests has been added to the ReactNative.Tests project. Additionally, the NUnit v3.41 nuGet package and the NUnit3TestAdapter v 3.5 nuGet package were added to the ReactNative.Tests project.
The NUnit3TestAdapter v 3.41 nuGet package could not be loaded in the ReactNative.Tests project so v3.5 (the latest) was used. This creates a version mismatch with the NUnit package and the nuGet packages used in the ReactNative.Net46.Tests project...
* The NMock3 library is not compatiable with Universal Windows Projects... Any TestFixtures that utilize the NMock3 library need to be isolated in the .NET test project(s)...
Moved NMock3 related tests from ReactiveNative.Shared.Tests to ReactNative46.Tests.
The majority of tests in JavaScriptModuleBaseTests.cs utilized NMock so the entire file was moved from the ReactiveNative.Shared.Tests to the ReactNative.Net46.Tests projects.
A handful of tests in JavaScriptModuleRegistryTests.cs utilized NMock. A specialized class inheriting from JavaScriptModuleRegistryTests was added to the ReactNative.Net46.Tests project. The specialized class "JavaScriptModuleRegistryNMockTests" contains only the NMock dependent tests and the base class contains all tests that can be shared.
All references to NMock have been removed from the test code in the ReactNative.Shared.Tests projects...
A reference to the ReactNative.Shared.Tests has been added to the ReactNative.Tests project. Additionally, the NUnit v3.41 nuGet package and the NUnit3TestAdapter v 3.5 nuGet package were added to the ReactNative.Tests project.
The NUnit3TestAdapter v 3.41 nuGet package could not be loaded in the ReactNative.Tests project so v3.5 (the latest) was used. This creates a version mismatch with the NUnit package and the nuGet packages used in the ReactNative.Net46.Tests project...
* Removing "MockJavaScriptExecutor.cs" from ReactNative.Tests because it is already included in ReactNative.Shared.Tests
* Renaming "JavaScriptModuleRegistryMockTests.cs" to "JavaScriptModuleRegistryNMockTests.cs" to match the class name...
* Renaming JavaScriptModuleRegistryMockTests.cs to match the included class name...
* Upgrade NUnit version in ReactNative.Tests project
* Upgrade NUnit nuget references in ReactNative.Net46.Tests project to also be NUnit 3.5.0.
NUnit upgraded to 3.5.0
NUnit3TestRunner upgraded to 3.5.1
* Syncing with upstream
* Removing UpgradeLog.htm; adding UpgradeLog.htm to .gitignore
* Adding appveyor.yml
* * ReactNative.Shared.Tests: Renamed JavascriptModuleRegistryTests.cs and the containing
class from JavascriptModuleRegistryTests to JavascriptModuleRegistrySharedTests.
* ReactNative.Net46.Tests: Renamed JavascriptModuleRegistryNMockTests.cs and the containing
class from JavascriptModuleRegistryNMockTests to JavascriptModuleRegistryTests. Changed the base class to
JavascriptModuleRegistrySharedTests.
* ReactNative.Tests: Added JavascriptModuleRegistryTests.cs to project that uses Univesal-specific mocking in place
of NMock. Inherited containing class from JavascriptModuleRegistrySharedTests.
* Adding new and renamed files
* Restoring the 0.27-stable branch implementations of some universal specific tests in JavaScriptModuleRegistryTests
* Removing npm install -g react-native-cli and react-native bundle components from the AppVeyor config
* Removing x86 and ARM builds and x86 tests from AppVeyor config
* Reverting to previous examples version
* Add ChakraCore as submodule, pinned to their release/1.3 branch
* Add wrapper ChakraCore project to ReactNative solution, delegating via msbuild
* Use ChakraCore.dll instead of Chakra.dll for non-UWP builds
Currently, the Image API we're using does not support loading images from a file path. You can use something like "ms-appdata:///local", but not "c:\tmp\". This change ensures the bundle path, which is the base path for the local assets, is a URI.
Fixes#338
Adds support for bundling assets into the project output. To test this feature on Playground, first run the command:
node local-cli/cli.js bundle --platform windows --dev true --entry-file ReactWindows\Playground\index.windows.js --bundle-output ReactWindows\Playground\index.windows.bundle --assets-dest ReactWindows\Playground\ReactAssets
Then, build the project using the Bundle configuration. This will copy the bundle and assets into the output folder (and also the .appxbundle, if you are creating one).
Jon Thysell
Alexander Sklar
Nick Gerleman
dannyvv
Vladimir Morozov
Canhua Li
Andrew Coates
Eric Rozell
Laura Bochenek
Ryan Linton
Andrew Forster
Matt Hargett
Matthew Podwysocki