[RFC] API Routes in Expo Router (#24429)# Why Servers are an important part of developing many different types of apps, but they're much harder to configure than they need to be. API Routes
[RFC] API Routes in Expo Router (#24429)# Why Servers are an important part of developing many different types of apps, but they're much harder to configure than they need to be. API Routes will enable users to express some abstract JavaScript code that runs in a server by simply creating a file in the app directory, and adding the `+api.js` suffix. For example, to securely interact with OpenAI, simply: ```ts // app/generate+api.ts import { ExpoRequest, ExpoResponse } from 'expo-router/server'; export async function POST(req: ExpoRequest): Promise<ExpoResponse> { const { prompt } = await req.json(); const json = await fetch('https://api.openai.com/v1/engines/text-davinci-003/completions', { headers: { 'Content-Type': 'application/json', // `OPENAI_API_KEY` is pulled from the .env file when running in Expo CLI. Authorization: `Bearer ${process.env.OPENAI_API_KEY ?? ''}`, }, method: 'POST', body: JSON.stringify({ prompt, max_tokens: 100, }), }).then(res => res.json()); // Return as JSON return ExpoResponse.json(json); } ``` This will be served at `http://localhost:8081/generate` with `npx expo` and can be used by making a request: ```sh $ curl -X POST -H "Content-Type: application/json" -d \'{"prompt":"Hello, my name is"}\' http://localhost:8081/generate ``` Expo Router polyfills the URL and `window.location` object on native to allow for universally requesting with a relative URL: ```js // Expo prepends the host and port to the URL automatically in development. const json = await fetch('/generate').then(res => res.json()); ``` # How - API Routes are bundled with Metro, leveraging all the same functionality as the rest of the app and website. - The project babel config is used to transpile the API routes. Indication is passed to the Babel caller via the `isServer` boolean. This can be used to change the preset based on the environment. - Each API route is bundled into a standalone file in the `dist/_expo` directory. This is akin to ncc, the tool we use to make Create Expo App download in ~1 second. - Create a new package `@expo/server` which includes the requisite middleware and runtime polyfills for the Expo server environment. - Add a new routes manifest which will be used by `@expo/server` to serve up the three types of routes: HTML routes, API routes, and not found routes (404s). - Add a new export `expo-router/server` (potentially will be moved to `expo/server`) which contains the `ExpoRequest` and `ExpoResponse` objects. These are all based on the WinterCG specification, and include some additional properties for interop with the Expo Router filesystem convention. These are inspired by Remix, SvelteKit, and Next.js for simplicity. - Add a new export mode `web.output: "server"` which can be used to export a dynamic server. Note: I may drop this for now and make server the default since there's no expo-specific hosting code that must be exported. - This PR adds the ability to host the app with an express server, different production adapters to follow. # Test Plan In addition to all the E2E Metro tests, I've added a new E2E runner which starts a server and pings different requests to ensure expected behavior. These run in the CLI as opposed to the `@expo/server` package. - resolve ENG-10057 ENG-8243 ENG-8082 ENG-8079 ENG-8242 ENG-8081 ENG-8080 ENG-9625 --------- Co-authored-by: Expo Bot <[email protected]> Co-authored-by: Cedric van Putten <[email protected]>
show more ...
fix(metro-config): fix native css modules (#23260)# Why - Add missing `unstable_styles` export on native for CSS Modules. --------- Co-authored-by: Expo Bot <[email protected]
fix(metro-config): fix native css modules (#23260)# Why - Add missing `unstable_styles` export on native for CSS Modules. --------- Co-authored-by: Expo Bot <[email protected]>
fix(metro-config): Fix css modules syntax. (#23086)# Why <!-- Please describe the motivation for this PR, and link to relevant GitHub issues, forums posts, or feature requests. --> # How
fix(metro-config): Fix css modules syntax. (#23086)# 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-config): add unstable_styles to css modules (#23002)# Why It's too confusing to have React Native styles be the default for CSS modules. This PR makes CSS Modules in Expo work as ex
feat!(metro-config): add unstable_styles to css modules (#23002)# Why It's too confusing to have React Native styles be the default for CSS modules. This PR makes CSS Modules in Expo work as expected by default. We now export (and squat) `unstable_styles` which can be used to access the CSS Modules as React Native Web style objects. This is a breaking change but only released in the alpha. # Test Plan Updated tests. # 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): strip `app/+html` files from client bundles. (#22881)# Why Prevent the contents of +html from leaking into the client bundle. This is only enabled when static rendering is enabled.
feat(metro): strip `app/+html` files from client bundles. (#22881)# Why Prevent the contents of +html from leaking into the client bundle. This is only enabled when static rendering is enabled. <!-- Please describe the motivation for this PR, and link to relevant GitHub issues, forums posts, or feature requests. --> # How If the file matches `app/+html*` and metro isn't compiling that file for node.js, then it will be removed. # Test Plan Added automated tests. --------- Co-authored-by: Expo Bot <[email protected]>
feat(metro-config, cli): CSS serializer (#22325)# Why In order to support static CSS in development mode, we need to update the metro serializer to support returning the JS and CSS assets. We n
feat(metro-config, cli): CSS serializer (#22325)# Why In order to support static CSS in development mode, we need to update the metro serializer to support returning the JS and CSS assets. We now inline the CSS in the HTML before sending to the client, this allows for testing how the website works with JS disabled. We use the same style tag id to continue to support HMR for styles during subsequent updates. This change also refactors how exports work to serialize JS and CSS at the same time (i.e. after the native transformations). <!-- 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-config): add postcss (#22032)# Why - Required for modifying CSS and supporting Tailwind on web (but also universally). - Eventually we'll want to add some postcss transforms by defa
feat(metro-config): add postcss (#22032)# Why - Required for modifying CSS and supporting Tailwind on web (but also universally). - Eventually we'll want to add some postcss transforms by default (standard in the web community). <!-- Please describe the motivation for this PR, and link to relevant GitHub issues, forums posts, or feature requests. --> # How - Write a `postcss` parser which loads the user config. - `postcss.config.js` and `postcss.config.json` are the only supported config files. https://github.com/webpack-contrib/postcss-loader/blob/ef332db57381ed1d8aaa4a9a20eec0e0b21fdb7c/src/utils.js#L64-L114 - Process input CSS with postcss config and pass output to standard CSS loading process. - TBD: More advanced Metro cache invalidation. - We currently have a basic hashing system which auto invalidates the transformer when the config file and browserslist options change. <!-- How did you build this feature or fix this bug and why? --> # Test Plan - Added minor tests for certain parts of the flow but nothing 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). --------- Co-authored-by: Expo Bot <[email protected]>
fix(metro-config): Escape octal characters in runtime CSS scripts. (#22054)# Why octal characters need to be escaped in strings. --------- Co-authored-by: Expo Bot <34669131+expo-bot@users
fix(metro-config): Escape octal characters in runtime CSS scripts. (#22054)# Why octal characters need to be escaped in strings. --------- Co-authored-by: Expo Bot <[email protected]>
feat(metro-config): add sass (#22031)# Why Standard feature for modern web support. # How - When a project has CSS setup and `sass` installed, they can use sass syntax in scss/sass files.
feat(metro-config): add sass (#22031)# Why Standard feature for modern web support. # How - When a project has CSS setup and `sass` installed, they can use sass syntax in scss/sass files. - Sass is compiled to CSS before it's passed to the standard CSS handling. This means that css modules also support sass. - Just like standard CSS support, importing external files is not currently supported. <!-- How did you build this feature or fix this bug and why? --> # Test Plan - tbd <!-- 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]>
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).