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]>
show more ...
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(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).
chore: migrate metro-config, dev-server (#18221)* chore: migrate metro CLI packages * fix deps * fix types * Update withMetroMultiPlatform.ts * Update yarn.lock