chore(cli): delete @expo/dev-server (#24272)# Why - I tried this before but the logs endpoint was blocking it. - I forked the dev server when I wrote the original `expo/cli`, been meaning to d
chore(cli): delete @expo/dev-server (#24272)# Why - I tried this before but the logs endpoint was blocking it. - I forked the dev server when I wrote the original `expo/cli`, been meaning to delete the original for a while. The duplicate code and indirection is making the new server features harder to implement. <!-- Please describe the motivation for this PR, and link to relevant GitHub issues, forums posts, or feature requests. --> # How - Copy/paste remaining code from `@expo/dev-server` in to `@expo/cli`. - Delete `@expo/dev-server`. - Drop unused `/logs` and json parser middleware. - Drop logging mocks. - Drop experimental Webpack native support. - Drop legacy react-native middleware support (no longer needed since everything is versioned). <!-- How did you build this feature or fix this bug and why? --> # Test Plan - Tests should keep passing. - Need to do some actual runs since there aren't any e2e tests for various parts of dev-server. <!-- Please describe how you tested this change and how a reviewer could reproduce your test, especially if this PR does not include automated tests! If possible, please also provide terminal output and/or screenshots demonstrating your test/reproduction. --> # Checklist <!-- Please check the appropriate items below if they apply to your diff. This is required for changes to Expo modules. --> - [ ] Documentation is up to date to reflect these changes (eg: https://docs.expo.dev and README.md). - [ ] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md) - [ ] This diff will work correctly for `npx expo prebuild` & EAS Build (eg: updated a module plugin). --------- Co-authored-by: Expo Bot <[email protected]>
show more ...
fix imports lint (#24051)# Why <!-- Please describe the motivation for this PR, and link to relevant GitHub issues, forums posts, or feature requests. --> # How <!-- How did you build
fix imports lint (#24051)# Why <!-- Please describe the motivation for this PR, and link to relevant GitHub issues, forums posts, or feature requests. --> # How <!-- How did you build this feature or fix this bug and why? --> # Test Plan <!-- Please describe how you tested this change and how a reviewer could reproduce your test, especially if this PR does not include automated tests! If possible, please also provide terminal output and/or screenshots demonstrating your test/reproduction. --> # Checklist <!-- Please check the appropriate items below if they apply to your diff. This is required for changes to Expo modules. --> - [ ] Documentation is up to date to reflect these changes (eg: https://docs.expo.dev and README.md). - [ ] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md) - [ ] This diff will work correctly for `npx expo prebuild` & EAS Build (eg: updated a module plugin). --------- Co-authored-by: Expo Bot <[email protected]>
feat(metro): use custom babel-transformer (#23607)# Why Historically, we've avoided using a custom Metro babel transformer because some users leverage this value to transform certain files. Ho
feat(metro): use custom babel-transformer (#23607)# Why Historically, we've avoided using a custom Metro babel transformer because some users leverage this value to transform certain files. However, we need to be able to pass custom options to the babel configuration like `metroTarget` and we also need to ensure `babel-preset-expo` is always used. These two aspects ensure Node.js environments can be accounted for in `babel-preset-expo`. <!-- Please describe the motivation for this PR, and link to relevant GitHub issues, forums posts, or feature requests. --> # How - Fork the upstream babel-transformer. - Modify the fork to use babel-preset-expo by default when a `babel.config.js` isn't defined. - Expose the `metroTarget` field to the Babel caller. This is either `client`, `node`, or `undefined`. When defined, we'll use this to strip server code, and use more focused babel transforms (not yet implemented). - Expose the fork under `@expo/metro-config/babel-transformer`. - Add docs on how to extend the Expo metro babel transformer. - Delete the previous wrapper that was used when no babel.config.js file was defined. <!-- How did you build this feature or fix this bug and why? --> # Test Plan <!-- Please describe how you tested this change and how a reviewer could reproduce your test, especially if this PR does not include automated tests! If possible, please also provide terminal output and/or screenshots demonstrating your test/reproduction. --> # Checklist <!-- Please check the appropriate items below if they apply to your diff. This is required for changes to Expo modules. --> - [ ] Documentation is up to date to reflect these changes (eg: https://docs.expo.dev and README.md). - [ ] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md) - [ ] This diff will work correctly for `npx expo prebuild` & EAS Build (eg: updated a module plugin). --------- Co-authored-by: Expo Bot <[email protected]> Co-authored-by: Aman Mittal <[email protected]>
fix(cli, metro-config): fix tests and types (#22867)
[cli] fix typecheck from react-native 0.72 upgrade (#22766)# Why follow up #22588 which disabled the cli typecheck # How using types from metro and fix typing issues # Test Plan cli
[cli] fix typecheck from react-native 0.72 upgrade (#22766)# Why follow up #22588 which disabled the cli typecheck # How using types from metro and fix typing issues # Test Plan cli ci passed
feat(cli, metro-config): environment variable support (#21983)# Why - It's nice to be able to use uncommitted values in your app, based on the environment. This feels very familiar to web devel
feat(cli, metro-config): environment variable support (#21983)# Why - It's nice to be able to use uncommitted values in your app, based on the environment. This feels very familiar to web developers. - Values that are prefixed with `EXPO_PUBLIC_` will be inlined in the bundle when bundling normally (e.g. not for Node.js). - `.env` files are loaded into memory and applied to the process during a run. This also means that they're available in `app.config.js`. - During development-only, environment variables are exposed on the `process.env` object (non-enumerable) to ensure they're available between fast refresh updates. <!-- Please describe the motivation for this PR, and link to relevant GitHub issues, forums posts, or feature requests. --> # How - Create new package `@expo/env` which is used to hydrate env variables in a unified way. I plan to open another PR in `eas-cli` which uses this package to fill in environment variables before uploading. NOTE: environment variables that are defined in eas.json are not available in Expo CLI when building locally, but are available in the cloud since they'll be on the process, this means they effectively emulate `.env.production`. - Update templates to gitignore local env files. - Add basic documentation to the versioned metro guide (more to come). <!-- How did you build this feature or fix this bug and why? --> # Test Plan - [ ] E2E rendering test - [ ] E2E Node.js rendering test - [x] Unit tests for serializer - [x] Tests for env package <!-- Please describe how you tested this change and how a reviewer could reproduce your test, especially if this PR does not include automated tests! If possible, please also provide terminal output and/or screenshots demonstrating your test/reproduction. --> # Checklist <!-- Please check the appropriate items below if they apply to your diff. This is required for changes to Expo modules. --> - [ ] Documentation is up to date to reflect these changes (eg: https://docs.expo.dev and README.md). - [ ] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md) - [ ] This diff will work correctly for `expo prebuild` & EAS Build (eg: updated a module plugin).
feat(metro-config, cli): CSS support for Metro web (#21941)# Why This PR moves the CSS support from Expo Router over to `expo/metro-config` behind a beta flag. This is because we need deeper i
feat(metro-config, cli): CSS support for Metro web (#21941)# Why This PR moves the CSS support from Expo Router over to `expo/metro-config` behind a beta flag. This is because we need deeper integration with Expo CLI and Metro in order to emit static CSS files in production bundles. CSS is required for media queries -> rehydration. - Related: https://github.com/expo/router/pull/397 https://github.com/expo/router/pull/223 <!-- Please describe the motivation for this PR, and link to relevant GitHub issues, forums posts, or feature requests. --> # How Instead of a babel transformer, we now use a custom "transformer" which gives us the ability to add extra metadata to a Metro module on export. This means we can pass the raw and processed CSS for writing to disk. The development version of CSS still uses script injection via JavaScript, meaning static rendering cannot currently be tested in development. CSS Modules are implemented (web-only currently) using lightningcss. The export is generated to work with React Native for web. Consider the following block: ```js export default { ...StyleSheet.create({ container: { $$css: true, _: 'hashed-container-id' } }) } ``` CSS Variables are not currently hashed, enabling the user to define variables in a global CSS file and access them in CSS Modules (subject to change in order to support native). CSS variables are accessible from the default export as strings: `styles['--color'] === '--color'`. ## Docs I've chosen to document in the versioned metro doc instead of the unversioned guide, this seems like a reasonable spot given the highly experimental nature of this feature. <!-- How did you build this feature or fix this bug and why? --> # Test Plan - Unit tests for conversion. - [x] Test in/out for transformer. - [ ] Test static export. - TBD for E2E <!-- Please describe how you tested this change and how a reviewer could reproduce your test, especially if this PR does not include automated tests! If possible, please also provide terminal output and/or screenshots demonstrating your test/reproduction. --> # Checklist <!-- Please check the appropriate items below if they apply to your diff. This is required for changes to Expo modules. --> - [ ] Documentation is up to date to reflect these changes (eg: https://docs.expo.dev and README.md). - [ ] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md) - [ ] This diff will work correctly for `expo prebuild` & EAS Build (eg: updated a module plugin).
feat(metro-config): support any entry file in development builds that don't use Expo dev client (#21643)# Why - React Native enforces that apps must use `index.js` as the entry file, this is hi
feat(metro-config): support any entry file in development builds that don't use Expo dev client (#21643)# Why - React Native enforces that apps must use `index.js` as the entry file, this is highly inconvenient and forces us to change the app entry on `expo prebuild` (cite: [prebuild side effects](https://github.com/expo/expo/blob/4d2795e/docs/pages/workflow/prebuild.mdx#side-effects) (`index.js` and `package.json` `scripts`)). - In #14964 I added support for production Android apps to use any entry point. - In #18381 I added the same support to iOS apps in production. - Development builds using `expo-dev-client` and Expo Go both use a manifest which support arbitrary entry points. - This just leaves development builds that don't have Expo code-loading support (e.g. no manifest/index.html where the script can be changed dynamically). # How - This PR introduces the virtual entry file `.expo/.virtual-metro-entry` which should never physically exist. When this endpoint is pinged, Expo CLI will rewrite the the URL to the correct entry point based on the project configuration. This enables us to fully drop the prebuild side-effect as no case will require an `index.js` (`index.bundle`) as the entry file. - The rewrite means Metro will never support a physical file located at `.expo/.virtual-metro-entry.js` as this will always be ignored. We could support forwarding the request if this file exists but we'll probably go the other way and assert if this file exists to mitigate possible confusion. - The name `.expo/.virtual-metro-entry.js` was chosen to be clear and long enough that users wouldn't try to actually create this file. - I originally tried using a middleware to perform the redirect but this wouldn't work with the HMR server which emulates pinging the endpoint in-memory. Because of this, I went with the metro `server.rewriteRequestUrl` function. > This feature is implemented in Expo's Metro configuration, meaning it should apply to `npx react-native start` (but this is untested and not officially supported). ## New Setup Instructions for non-prebuild users Non-prebuild projects will need to modify their `AppDelegate.mm` as follows: ```diff - (NSURL *)sourceURLForBridge:(RCTBridge *)bridge { #if DEBUG - return [[RCTBundleURLProvider sharedSettings] jsBundleURLForBundleRoot:@"index"]; + return [[RCTBundleURLProvider sharedSettings] jsBundleURLForBundleRoot:@".expo/.virtual-metro-entry"]; #else return [[NSBundle mainBundle] URLForResource:@"main" withExtension:@"jsbundle"]; #endif } ``` And their `android/app/src/main/java/***/MainApplication.java`: ```diff @Override protected String getJSMainModuleName() { - return "index"; + return ".expo/.virtual-metro-entry"; } ``` This is of course in addition to the `android/app/build.gradle`: ```groovy entryFile = file(["node", "-e", "require('expo/scripts/resolveAppEntry')", projectRoot, "android", "absolute"].execute(null, rootDir).text.trim()) ``` And iOS production change: ``` shellScript = "if [[ -f \"$PODS_ROOT/../.xcode.env\" ]]; then\n source \"$PODS_ROOT/../.xcode.env\"\nfi\nif [[ -f \"$PODS_ROOT/../.xcode.env.local\" ]]; then\n source \"$PODS_ROOT/../.xcode.env.local\"\nfi\n\n# The project root by default is one level up from the ios directory\nexport PROJECT_ROOT=\"$PROJECT_DIR\"/..\n\nif [[ \"$CONFIGURATION\" = *Debug* ]]; then\n export SKIP_BUNDLING=1\nfi\nif [[ -z \"$ENTRY_FILE\" ]]; then\n # Set the entry JS file using the bundler's entry resolution.\n export ENTRY_FILE=\"$(\"$NODE_BINARY\" -e \"require('expo/scripts/resolveAppEntry')\" $PROJECT_ROOT ios relative | tail -n 1)\"\nfi\n\n`\"$NODE_BINARY\" --print \"require('path').dirname(require.resolve('react-native/package.json')) + '/scripts/react-native-xcode.sh'\"`\n\n"; ``` # Test Plan ### Continuous(-ish) - Updated the templates to use this new format. ### Quick test - Start the dev server and ping the entry URL directly: - `http://localhost:8081/.expo/.virtual-metro-entry.bundle?platform=web&dev=true&minify=false&modulesOnly=true&runModule=false&shallow=true` - The redirected URL should show in the `sourceURL` at the end of the file. ### E2E - Prebuild, then apply the native changes in a local projects - Use the following `metro.config.js` (you don't need to use the latest Expo CLI for this to work): ```js // Learn more https://docs.expo.io/guides/customizing-metro const { getDefaultConfig } = require("../../expo/packages/@expo/metro-config"); // const { getDefaultConfig } = require('expo/metro-config'); module.exports = getDefaultConfig(__dirname); ``` - `npx expo run:ios` and `npx expo run:android` should point to `index.bundle` - Changing the `main` field in the package.json or deleting `index.js` should continue to work when you reload the app. # Checklist <!-- Please check the appropriate items below if they apply to your diff. This is required for changes to Expo modules. --> - [ ] Documentation is up to date to reflect these changes (eg: https://docs.expo.dev and README.md). - [ ] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md) - [ ] This diff will work correctly for `expo prebuild` & EAS Build (eg: updated a module plugin). --------- Co-authored-by: Expo Bot <[email protected]>
feature(cli): add custom inspector proxy based on `metro-inspector-proxy` (#21449)# Why Fixes ENG-7467 Related #21265 This is an initial draft to extend the CDP functionality of `metro-in
feature(cli): add custom inspector proxy based on `metro-inspector-proxy` (#21449)# Why Fixes ENG-7467 Related #21265 This is an initial draft to extend the CDP functionality of `metro-inspector-proxy`. # How The implementation is slightly wonky around the `ExpoInspectorDevice`. We want to reuse as much as possible from `metro-inspector-proxy`, but we need to add stateful data per device. In order to achieve that, we generate a new class type, based on the user's installed `metro-inspector-proxy`. This makes everything less readable but should include future updates in these classes. As for the `ExpoInspectorProxy`, to avoid having to do the same thing, we just wrap the whole inspector class and reuse what we can. The device map is "linked" within the original inspector proxy instance, making the data available to all methods that need it. # Test Plan Enable this feature with `EXPO_USE_CUSTOM_INSPECTOR_PROXY=1` - [x] See tests for the actual CDP events we handle. - [ ] See tests on the "bootstrapping code" to create the inspector and devices. # Checklist <!-- Please check the appropriate items below if they apply to your diff. This is required for changes to Expo modules. --> - [ ] Documentation is up to date to reflect these changes (eg: https://docs.expo.dev and README.md). - [ ] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md) - [ ] This diff will work correctly for `expo prebuild` & EAS Build (eg: updated a module plugin). --------- Co-authored-by: Evan Bacon <[email protected]>
feat(cli): auto setup typescript during start (#21475)# Why - Some users are confused about how to use the fully automated TypeScript setup. It currently runs when you run `npx expo start` in a
feat(cli): auto setup typescript during start (#21475)# Why - Some users are confused about how to use the fully automated TypeScript setup. It currently runs when you run `npx expo start` in a project with `tsconfig.json` or any TypeScript file in the project. - This change will run the TypeScript check continuously until TypeScript is setup. This only applies to projects using Metro, and currently is only run in `npx expo start`, and the run commands (when the server is started in the current window, e.g. not headless mode). <!-- Please describe the motivation for this PR, and link to relevant GitHub issues, forums posts, or feature requests. --> # How - Fork the `runServer` function from Metro into the CLI so we can access the Metro bundler instance directly. - Use Metro's native file watching to observe new TypeScript files being added to the project (within the observable files). This is fast and ensures we don't accidentally block a thread that otherwise could've been used for bundling. - The TypeScript continuous check only runs once, if you remove TypeScript and add it back in the same process, then nothing happens. This is a performance optimization. - If TypeScript is enabled while the process is running, the user will not be prompted to install, the packages will just install in the project. Failures will be displayed in the running process, and no more attempts will be made. - If TypeScript is detected on start then the existing system will be used and the continuous check will be skipped, this means projects already using TypeScript won't have any technical performance hit. <!-- How did you build this feature or fix this bug and why? --> # Test Plan - In a project without TypeScript: - `npx expo` - `touch tsconfig.json` or `mv index.js index.tsx` or `touch foo.tsx` - TypeScript is automatically installed for the project. - `EXPO_NO_TYPESCRIPT_SETUP` voids this behavior - Added unit tests. <!-- Please describe how you tested this change and how a reviewer could reproduce your test, especially if this PR does not include automated tests! If possible, please also provide terminal output and/or screenshots demonstrating your test/reproduction. --> # Checklist <!-- Please check the appropriate items below if they apply to your diff. This is required for changes to Expo modules. --> - [ ] Documentation is up to date to reflect these changes (eg: https://docs.expo.dev and README.md). - [ ] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md) - [ ] This diff will work correctly for `expo prebuild` & EAS Build (eg: updated a module plugin). --------- Co-authored-by: Expo Bot <[email protected]> Co-authored-by: Cedric van Putten <[email protected]>
feat(metro-config): enable unstable_allowRequireContext (#19257)* unstable_allowRequireContext * fix build files * Update CHANGELOG.md * Update packages/@expo/cli/CHANGELOG.md Co-author
feat(metro-config): enable unstable_allowRequireContext (#19257)* unstable_allowRequireContext * fix build files * Update CHANGELOG.md * Update packages/@expo/cli/CHANGELOG.md Co-authored-by: Expo Bot <[email protected]> Co-authored-by: Expo Bot <[email protected]>
chore: migrate metro-config, dev-server (#18221)* chore: migrate metro CLI packages * fix deps * fix types * Update withMetroMultiPlatform.ts * Update yarn.lock
chore: migrate config, config-plugins, config-types, prebuild-config (#17958)
fix(cli): fix type errors (#16724)* fix(cli): fix type errors * Update CHANGELOG.md * Update packages/@expo/cli/CHANGELOG.md Co-authored-by: Expo Bot <[email protected]
fix(cli): fix type errors (#16724)* fix(cli): fix type errors * Update CHANGELOG.md * Update packages/@expo/cli/CHANGELOG.md Co-authored-by: Expo Bot <[email protected]> * fix typecheck * Update yarn.lock * Update package.json * Update MetroTerminalReporter.ts Co-authored-by: Expo Bot <[email protected]>