Conversation
# Why This has annoyed me a few times. The commands that `getRunningProcess` runs can cause the CLI to hang. Since it's there to be useful in case of a conflicting process using the default port, this is a very unfortunate moment to hang. This is seeminly caused by two causes: - the specific commands and piped shell commands in this file may not resolve and exit - the sync execution without a timeout is risky for the above reason # How - Switch the commands to cleaner equivalents so we don't need extra commands to parse their outputs and can remove the pipes - Switch to `@expo/spawn-async` and add a low timeout # Test Plan - Unit tests updated, but they're quite mocked - Run a second process of `expo start` to test the conflict # Checklist <!-- Please check the appropriate items below if they apply to your diff. --> - [x] I added a `changelog.md` entry and rebuilt the package sources according to [this short guide](https://github.com/expo/expo/blob/main/CONTRIBUTING.md#-before-submitting) - [ ] This diff will work correctly for `npx expo prebuild` & EAS Build (eg: updated a module plugin). - [ ] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md)
… env (#43037) # Why Follow-up to #42763 I'm currently looking at updating loading envs in the CLI to use the same implementation and switch away from `@expo/env`'s deprecated implementation. As part of this, I'm also looking at reloading from env files for `MetroBundlerDevServer`. We're already checking for `typeof systemEnv === 'undefined'` before copying values, and this is a guarantee we're carrying through a lot of layers in our implementation. However, `dotenv-expand`, when I was porting it in #42763 had a peculiar change that makes our tests fail. I've now realised that this was an unintentional failure. When a variable in a parsed env file was already set in the source environment and identical, the bailout used the existing value. tldr: Without this change environment variables aren't updating properly. `dotenv-expand` having changed versions between `expo/expo` and new projects explains why we didn't notice this before. # How - Swap incorrect fallback after checking `prev === next` in `expand` which was changed in `dotenv-expand` in a patch as well See: motdotla/dotenv-expand@b680e4a # Test Plan - Existing unit test was updated to reflect this change # Checklist <!-- Please check the appropriate items below if they apply to your diff. --> - [x] I added a `changelog.md` entry and rebuilt the package sources according to [this short guide](https://github.com/expo/expo/blob/main/CONTRIBUTING.md#-before-submitting) - [ ] This diff will work correctly for `npx expo prebuild` & EAS Build (eg: updated a module plugin). - [ ] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md)
…place module loading/evals with it (#42884) # Why We can replace a lot of `require-from-string` harnesses and boilerplate code with our own. This allows us to drop in standard code that handles more cases and unifies them. The main motivation here is to: - Unify TypeScript handling/transforms - Use `stripTypeScriptTypes`, if it's available - Let Node.js handle TypeScript when we're async-loading and can use its built-in behaviour - Let Node.js handle requiring ESM since that's within our supported range (Node 20.19+, 22.12+, 24) - Drop `sucrase`, since it's heavy and not the best module for our use-case anymore In the future, centralising on `@expo/require-utils` gives us a place to unify some cross-project logic that we're otherwise duplicating in multiple places. For example, we could swap this in for other utilities like `resolve-from` or our global resolution code. Replacing `sucrase` on `@expo/config` should speed up CLI load times and using `typescript` and the built-in `require` / `stripTypeScriptTypes` APIs means we're also ready for Node.js' built-in type stripping. # How - Add `@expo/require-utils` - Has an optional peer dependency on `typescript` - Exposes `evalModule`, `loadModule`, and `loadModuleSync` - Switch `expo-modules-autolinking` to `@expo/require-utils`' `evalModule` - Switch `@expo/config` to `loadModuleSync` - Switch `@expo/cli` to `evalModule` - Add `@babel/code-frame` error framing to `@expo/require-utils` - Pipe TypeScript diagnostics from `transpileModule` to `@babel/code-frame` # Test Plan - E2E tests cover all changes here - ~~Test manually against Node 20~~ CI covers this - Test manually against Node 22 - Test manually against Node 24 - Test manually with various Node flags that manipulate require-esm and type-stripping - Works fine with `--no-experimental-strip-types` - Issues a warning & error as expected with `--no-experimental-require-module` with TypeScript and ESM # Checklist <!-- Please check the appropriate items below if they apply to your diff. --> - [x] I added a `changelog.md` entry and rebuilt the package sources according to [this short guide](https://github.com/expo/expo/blob/main/CONTRIBUTING.md#-before-submitting) - [ ] This diff will work correctly for `npx expo prebuild` & EAS Build (eg: updated a module plugin). - [ ] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )