<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/rss.xsl.xml"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
    <title>Changes in LaunchBrowserImplWindows.ts</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>46f023fa - [RFC] API Routes in Expo Router (#24429)</title>
        <link>http://172.16.0.5:8080/history/expo/packages/@expo/cli/src/start/server/middleware/inspector/LaunchBrowserImplWindows.ts#46f023fa</link>
        <description>[RFC] API Routes in Expo Router (#24429)# WhyServers are an important part of developing many different types ofapps, but they&apos;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 &apos;expo-router/server&apos;;export async function POST(req: ExpoRequest): Promise&lt;ExpoResponse&gt; {  const { prompt } = await req.json();  const json = await fetch(&apos;https://api.openai.com/v1/engines/text-davinci-003/completions&apos;, {    headers: {      &apos;Content-Type&apos;: &apos;application/json&apos;,      // `OPENAI_API_KEY` is pulled from the .env file when running in Expo CLI.      Authorization: `Bearer ${process.env.OPENAI_API_KEY ?? &apos;&apos;}`,    },    method: &apos;POST&apos;,    body: JSON.stringify({      prompt,      max_tokens: 100,  }),  }).then(res =&gt; 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 &quot;Content-Type: application/json&quot; -d \&apos;{&quot;prompt&quot;:&quot;Hello, my name is&quot;}\&apos; 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(&apos;/generate&apos;).then(res =&gt; 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: &quot;server&quot;` which can be used toexport a dynamic server. Note: I may drop this for now and make serverthe default since there&apos;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&apos;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 &lt;34669131+expo-bot@users.noreply.github.com&gt;Co-authored-by: Cedric van Putten &lt;me@bycedric.com&gt;

            List of files:
            /expo/packages/@expo/cli/src/start/server/middleware/inspector/LaunchBrowserImplWindows.ts</description>
        <pubDate>Fri, 15 Sep 2023 23:04:53 +0000</pubDate>
        <dc:creator>Evan Bacon &lt;bacon@expo.io&gt;</dc:creator>
    </item>
<item>
        <title>edeec536 - chore(cli): delete @expo/dev-server (#24272)</title>
        <link>http://172.16.0.5:8080/history/expo/packages/@expo/cli/src/start/server/middleware/inspector/LaunchBrowserImplWindows.ts#edeec536</link>
        <description>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.&lt;!--Please describe the motivation for this PR, and link to relevant GitHubissues, forums posts, or feature requests.--&gt;# 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).&lt;!--How did you build this feature or fix this bug and why?--&gt;# Test Plan- Tests should keep passing.- Need to do some actual runs since there aren&apos;t any e2e tests forvarious parts of dev-server.&lt;!--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.--&gt;# Checklist&lt;!--Please check the appropriate items below if they apply to your diff.This is required for changes to Expo modules.--&gt;- [ ] 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` &amp; EAS Build(eg: updated a module plugin).---------Co-authored-by: Expo Bot &lt;34669131+expo-bot@users.noreply.github.com&gt;

            List of files:
            /expo/packages/@expo/cli/src/start/server/middleware/inspector/LaunchBrowserImplWindows.ts</description>
        <pubDate>Wed, 06 Sep 2023 17:37:08 +0000</pubDate>
        <dc:creator>Evan Bacon &lt;bacon@expo.io&gt;</dc:creator>
    </item>
</channel>
</rss>
