[tools] Fix expotools not rebuilding on source change (#20846)
feat(expotools): use swc to compile source files (#20790)# Why - We use swc to compile Expo CLI, it's really fast. ## Before `time yarn tsc` -- `14.22s` ## After `time yarn build` --
feat(expotools): use swc to compile source files (#20790)# Why - We use swc to compile Expo CLI, it's really fast. ## Before `time yarn tsc` -- `14.22s` ## After `time yarn build` -- `0.67s` > Over 21x faster. # How - Wrote a Taskr file that bundled the code similar to before. One very notable difference is that type-checking is skipped. - Not sure if the `patch`, `sh`, `jar`, `txt` files should be copied into the build folder. Looks like they weren't being copied over with tsc. # Test Plan - `yarn clean && yarn et -h`
show more ...
Deprecate source-login-scripts.sh (#18330)# Why the `source-login-scripts.sh` introduced a lot of pain where the community reported much build errors from it. it doesn't support shells other tha
Deprecate source-login-scripts.sh (#18330)# Why the `source-login-scripts.sh` introduced a lot of pain where the community reported much build errors from it. it doesn't support shells other than zsh and bash. this pr find a new way to deal with xcode building issues that it cannot find the correct nodejs path. close ENG-4864 close ENG-5242 # How react-native introduces `.xcode.env` and `.xcode.env.local` for developers to override the `$NODE_BINARY`: https://github.com/facebook/react-native/pull/33546 to make sure building success from expo-constants, expo-updates, and also the app target when generating bundles. i would like to reuse the `.xcode.env` and `.xcode.env.local` from react-native. this pr further generates `.xcode.env.local` automatically for the app during `pod install`. we can ensure that `pod install` is executed from shell and nodejs is available. so we will generate `export NODE_BINARY="$(command -v node)"` in the `.xcode.env.local`. for xcode, the path will be `$PODS_ROOT/../.xcode.env.local`, every xcode subprojects can source the file to get correct `$NODE_BINARY`. # Test Plan - building bare-expo from xcode (opening xcode by macos finder) - building bare-expo by `yarn ios` - updates e2e ci passed - building expo-go (prerequisite: #18344) Co-authored-by: James Ide <[email protected]>
Upgrade to react-native 0.66 (#15914)# Why follow up https://github.com/expo/expo/pull/15817#discussion_r781366360 after we use the react-native from npm, the react-native version we used in ex
Upgrade to react-native 0.66 (#15914)# Why follow up https://github.com/expo/expo/pull/15817#discussion_r781366360 after we use the react-native from npm, the react-native version we used in expo-go is decoupled with other stuffs. that makes us upgrade react-native easier. # How 1. update versions in package.json 2. sync changes from [react-native-upgrade-helper](https://react-native-community.github.io/upgrade-helper/?from=0.64.2&to=0.66.4) 3. `RCTComponentData` changed its designated initializer in react-native 0.65. to make it compatible with older version, i introduced the `EXComponentDataCompatibleWrapper` class to support different versions. 4. [react-native-lab] to fix expo-go build error, we should patch react-native to use the codegen library from its repo but not from node_modules: https://github.com/expo/react-native/pull/29. # Test Plan - CI passed - bare-expo build & launch test - unversioned expo-go build & launch test
[bare-expo] Use official react-native (#15817)# Why from sdk 43, we've tried to use official react-native in our bare template. that would be good if we do this also in bare-expo and our tests w
[bare-expo] Use official react-native (#15817)# Why from sdk 43, we've tried to use official react-native in our bare template. that would be good if we do this also in bare-expo and our tests will be more like a real app which user would have. this change will also reduce android CI time because we don't need to build react-native AAR. (test-suite android from about 30m -> 23m) close ENG-2234 # How - remove `react-native-lab/react-native` from yarn workspace - remove building android AAR from our fork - remove dev-menu and async-storage code because our forked react-native removed the registration. the only purpose of `react-native-lab/react-native` is for expo-go versioned code after this pr. # Test Plan - CI green - `et remove-sdk -p {android,ios} -s 44.0.0 ; et add-sdk -p {android,ios} -s 44.0.0` and check versioning right
[tools] Move tools/expotools one folder up (#11410)
Move tools/bin to bin
[expotools] Add `expotools`/`et` to binAdded convenience commands based off of the setup in Universe. There are two scripts named `expotools` and `et` that do the same thing. They use Nix to build
[expotools] Add `expotools`/`et` to binAdded convenience commands based off of the setup in Universe. There are two scripts named `expotools` and `et` that do the same thing. They use Nix to build and track a copy of Expotools so that if there are any changes to Expotools, we display a prompt to the developer on the next run so that everyone is running the correct copy of Expotools for their checkout of the repo.The Nix package for expotools ignores the `build` and `node_modules` directories because Nix creates those build artifacts itself when creating the package. To ignore those directories, we use a negated version of `lib.sourceByRegex`.Test plan: run `expotools` in the Expo repo and get a prompt to build Expo tools. Then run `yarn` in expotools to build it normally, without Nix, which generates the build and node_modules directories. Run `expotools` again to verify Nix reuses the old expotools without letting those directories bust the Nix cache.
[ci] Start using nix
[yarn] Add a script to check the current version of Yarn (#2314)Since we aren't using Nix to control the version of Yarn, in practice we've seen several people have different versions of Yarn insta
[yarn] Add a script to check the current version of Yarn (#2314)Since we aren't using Nix to control the version of Yarn, in practice we've seen several people have different versions of Yarn installed -- I've seen this twice already. This commit adds a script called `check-yarn` that looks at your version of Yarn and compares (using semver) its version against a minimum desired version that is hard-coded. The script runs as a "preinstall" script and not in `.envrc` because `yarn --version` is a bit slow and takes about 250ms on my machine and making `cd` feel noticeable is annoying. Also actually enabled `source_local` in `.envrc` for good measure. Test plan: Uninstalled the latest version of Yarn and ran `yarn` in the repository root and got the warning message about my Yarn version. Upgraded Yarn and saw the message go away.
[secrets] Add `lock` and `unlock` scripts to run git-crypt with the right keyThese are convenience scripts that use the right key. I also added an `.envrc` file that adds tools/bin to PATH.