```yaml
---
slug: expo-community-flipper-retired
published: 2023-08-04T18:19:00-07:00
description: Thoughts on "completing" an open source project
excerpt: That moment when you're comfortable putting a temporary project to rest.
changelog: ~
---
```

With [the release of Expo 48](https://blog.expo.dev/expo-sdk-48-ccb8302e231), `expo-community-flipper` (gh)[https://github.com/jakobo/expo-community-flipper] (npm)[https://www.npmjs.com/package/expo-community-flipper] can finally declare its purpose fulfilled. A year ago, I was trying to debug redux inside of the Chrome Debugger and nearly lost my mind. It wasn't just a bad experience. It was an **awful** experience, defined by `console.log` and prayers.

There was [react-native debugger](https://github.com/jhen0409/react-native-debugger) and [reactotron](https://github.com/infinitered/reactotron), but nothing that worked for me specifically. My setup was **weird** but not unlikely. WSL2, Windows 11, and the iOS app running via Expo's custom dev app. Only one thing really worked with this setup, and that was [Flipper](https://fbflipper.com/). Plus, I could finally see FPS information for animations as an added bonus (more on that later).

## Expo & Flipper in a Graph

![Download statistics for expo-community-flipper](https://user-images.githubusercontent.com/1795/222308501-930d3ee3-1121-4895-801d-0c3a544d7f88.png)

One of the problems with using Flipper was that it required editing the Podfile. This is all well and good if you're using react-native on a mac and love running XCode yourself. But if you're that weird-dev-guy with WSL 2, running XCode is ~~impossible~~ legally troublesome at best. As a lucky coincidence, Expo pushed out SDK 43 and began documenting their config plugin system: scriptable JavaScript that could edit & change build files as part of a remote CI or build pipeline.

And so, starting with SDK 43, I released the [first version of expo-community-flipper on npm](https://www.npmjs.com/package/expo-community-flipper/v/43.0.0) into the wild. With every subsequent SDK, I'd check the [expo base template](https://github.com/expo/expo/tree/main/templates/expo-template-bare-minimum/ios) and the [React Native Upgrade Helper](https://react-native-community.github.io/upgrade-helper/) and focus on changes to the `Podfile`.

It was a scramble. It wasn't always obvious _what_ changed. Sometimes a random `AppDelegate.m` was the culprit, other times it was the ruby scripts to include Flipper upstream in the React Native libraries. It got better though with every release.

* [I wrote a post for the Expo team](https://blog.expo.dev/developing-react-native-with-expo-and-flipper-8c426bdf995a) to go along with my WSL 2 article I did earlier for them
* [Alexandre Moureaux hooked performance monitoring in](https://www.youtube.com/watch?v=Yl6gj0ZLB3Y) and gave a talk
* [Abdulrahman wrote an article](https://medium.com/@abdulrahmanhashem/8-ways-to-debug-your-react-native-app-with-expo-the-comprehensive-guide-538655cf1684)

Debugging was finally _easier_. It would just be nice to get out of reaction-mode when new SDKs were imminent.

## Enter the Expo Team and Merging Up

SDK 47 marked the beginning of the end in a positive way. There were changes coming that would break `expo-community-flipper`, and the expo team wanted to be proactive about the changeset. This was the first time in the project's history that `expo-community-flipper` was going to be SDK ready on launch. This proactive outreach got the wheels turning though. What if expo just did the "Flipper bits" itself? They've got a much better testing suite, there are already plugins for modifying the `Podfile`, and then Flipper could get the attention it deserved.

Ideally, SDK 47 would be the last time we'd have to do this npm release dance. After talking with the Expo team, we [launched a plan to merge `expo-community-flipper` upstream](https://github.com/jakobo/expo-community-flipper/issues/41) into the `build-properties` plugin. [It landed in January](https://github.com/expo/expo/pull/20890) and Flipper support became an official part of the `expo-config-build-properties` plugin in SDK 48.

This section is pretty uneventful because the Expo team is just that good. I worked with [Kudo Chien](https://github.com/Kudo) for most of the PR and integration, and Expo had the infrastructure to absorb the changeset without issue. I was honestly impressed at how smooth everything went. I also like the "Why" and "How" sections they encourage on PRs for explaining their changes.

## Ending `expo-community-flipper`

Finally came the goodbyes. A README change, a release on SDK 48 with a `peerDependency` that keeps it from running against newer Expo versions, and an `npm deprecate`. And it was done. With Expo SDK 49 released and deprecating 46, and SDK 50 on the horizon, `expo-community-flipper` will be finally be archived and the project complete.

It's surreal. It feels good. Not many open source projects get a happily ever after.

Thoughts on "completing" an open source project

Link

code

strong

Document

The End of expo-community-flipper

```yaml
---
slug: developing-react-native-with-expo-and-flipper
published: 2021-12-07T01:00:00.000Z
description: Goodbye Chrome Debugger, hello Flipper
repost:
  url: https://blog.expo.dev/developing-react-native-with-expo-and-flipper-8c426bdf995a
  text: This article was written for the Expo Blog and appeared with the title _Developing React Native with Expo and Flipper_. It's been reproduced here with permission.
changelog:
  - on: 2021-12-03
    note: There’s now an Expo community plugin for setting up Flipper in your Expo projects. The section on Flipper integration was updated to reflect this change.
---
```

There’s a lot of great React Native modules out there, but most of them require a custom iOS or Android build, leaving “ejecting” as the only option for Expo users. That changed in SDK >42, when Expo added the ability for Expo Application Services to create custom development builds of your app.

What’s a custom development build? It’s not just any Expo Go app, it’s your Expo Go app; complete with any React Native module you ever wanted, all without ever having to hit the eject button.

And now that Expo 43 includes React Native 0.63, [Flipper by Facebook](https://fbflipper.com/) is available by default; there’s no better time to ditch the old “Chrome Developer Tools” way of debugging your React Native app. Not only will you gain access to device information and crash logs, you’ll also have Flipper’s amazing plugin library. Everything from Apollo to Redux debuggers are in there.

If you’d like to skip to the end result, check out the [jakobo/expo-cdc-example](https://github.com/jakobo/expo-cdc-example) repo as that’s what we’ll be building towards.

## Overview
- Configuring your code for EAS
- Creating a development build of your app
- Connecting to your app via Flipper
- Final considerations

## Create an EAS-Friendly Expo App
We’re going to start our journey by making a run-of-the-mill Expo application (install Expo CLI if needed with `npm install -g expo-cli`). When we run `expo init -t expo-cdc-example`, we’ll be given a standard Expo application, configured for Typescript. If you would prefer vanilla JavaScript, just omit the `-t` option. The result (minus our hidden folders and our lockfile) looks like this:

```
/
|- assets
|- app.json
|- App.tsx
|- babel.config.js
|- package.json
|- tsconfig.json
```

From here, we can run `expo start` and view our Expo app. We could also build locally, but what we’re really looking for is to let someone else do all the work for us. This is doubly true if we’re developing on Windows, as XCode isn’t even an option for making an iOS app. Enter Expo Application Services (EAS).

EAS lets you use Expo’s hardware to build your iOS/Android application, and has its own CLI. You can use EAS for building non-expo applications as well, so the EAS cli isn’t bundled with Expo. We’ll need to install it globally like we did with our `expo-cli`.

    npm install -g eas-cli

Let that run, and you’ll have a new `eas` command available. The EAS CLI doesn’t have an `init` command, and while running the `eas` build command will generate the configuration file for us, we’ll have greater control if we create the file ourselves. Create a file named `eas.json` in your application root and copy/paste the following configuration in:

```json
{
  "cli": {
    "version": ">= 0.34.0"
  },
  "build": {
    "base": {
      "env": {}
    },
    "development": {
      "extends": "base",
      "developmentClient": true,
      "distribution": "internal",
      "releaseChannel": "default",
      "android": {
        "buildType": "apk"
      }
    },
    "production": {
      "extends": "base",
      "distribution": "store",
      "releaseChannel": "stable",
      "android": {
        "buildType": "app-bundle"
      }
    }
  }
}
```

This sets up EAS to build something we’ll call a “preview” build. It will behave just like our production app, but it’s claimed ownership of the default release channel. By utilizing `releaseChannel: "default"` in our development build, and not our production builds, we can make sure that an accidental `expo publish` doesn’t push code to our live application. There’s [a lot more to `eas.json`](https://docs.expo.dev/build/eas-json/) than we’re covering in this article, but the above is enough for us to launch our builds. If you’re already using the default channel for your app store releases, you can change value of the `releaseChannel` property.

We can now tell EAS to build our app. We’ll want to specify our build profile preview as part of the command.

If this is your first time running EAS, you’ll want to associate any iOS devices with your ad hoc provisioning profile. You can [follow the steps in the Expo documentation](https://docs.expo.dev/build/internal-distribution/), or just run `eas device:create` and follow the prompts. To generate our build, we just need to run `eas build --profile=preview`.

EAS will be off building things, and you can go get a cup of coffee. ☕

After a while, you’ll have a shiny build that you can install on your iOS/Android device! EAS runs in the background too, so no need to wait for a build to finish, you can get back to coding.

## Configuring EAS For a Development Build

So far, we’ve created an Expo app, we’ve configured EAS, and we’ve kicked off a custom build. But EAS doesn’t just let you make custom production builds, it **lets you make development builds too!** That’s right, it is your own Expo Go, with your own modules. And we’ll be using EAS to build it.

Enabling a development builds means creating a new profile in our `eas.json`. These additions should go alongside your preview build.

```json5
{
  "build": {
    // ...
    "devclient": {
      "extends": "base",
      "releaseChannel": "default",
      "distribution": "internal",
      "developmentClient": true,
      "android": {
        "buildType": "apk"
      },
      "ios": {
        "simulator": true
      }
    }
  }
}
```

Our new profile, `devclient` adds a few EAS options. The `developmentClient` flag tells EAS that we want a custom build of the Expo development app, and the `ios.simulator` field tells EAS not to create an iOS app, but a bundle that’s designed for the iOS Simulator.

Now, kick off your new build and go get more coffee. ☕

    eas build --profile=devclient

When that finishes up, you’ll have a custom simulator build. When you install that on your simulator and launch it, it will look different than your usual Expo Go app.

![The Expo Custom Development Client launch screen](https://user-images.githubusercontent.com/1795/146845551-1bd86cb8-8236-4805-ba10-2bf24ab0cb82.png)
_The Expo Custom Development Client launch screen_

Instead of the usual expo start command, it tells us our app needs to be started with the `--dev-client` flag, so let’s do that. Stop your expo start if it’s running, and restart it with `expo start --dev-client`.

The project will show up in your development build with a URL structure of `exp+<project>://expo-development-client/…`. The `exp+<project>` protocol helps the native OS tell the difference between your custom Expo app and any others you might have on the simulator or device.

So long, Expo Go, hello Development Builds. 💅

## Hello Native Modules, Hello Flipper

All of the above setup needs to be done exactly once, and the payoff is huge. We’re going to get a better debugger for React Native, called [Flipper](https://fbflipper.com/), by Facebook. Go download the app, and we’ll set up our development build to use this native module.

First, we’ll need to install Flipper and its dependencies, which is a straightforward pair of command: `expo install react-native-flipper react-devtools-core` for our expo related code and `yarn install expo-community-flipper` for our build plugin we'll be using later.
Then, we’ll need to tell our App to connect to Flipper in our `App.tsx` file:

```tsx
// App.tsx
import { connectToDevTools } from "react-devtools-core";
if (__DEV__) {
  connectToDevTools({
    host: "localhost",
    port: 8097,
  });
}
```

Since we’ve added a new native module, we’ll need to create a new development build that has our native iOS and Android code bundled in. Because Flipper also requires changes to our app’s `Podfile`, we’re also going to make use of Expo’s [Config Plugin](https://docs.expo.dev/guides/config-plugins/) system. Because we already installed the [community Flipper plugin](https://www.npmjs.com/package/expo-community-flipper), it's as easy as adding the plugin to our `app.json`.

```json5
{
  "expo": {
    // ...
    "plugins": ["expo-community-flipper"]
}
```

One last time (and one last ☕): `eas build --profile=devclient`

Install the new build on your simulator, open up the Flipper App and it just works 🤯

You can repeat this for any Native Module you want, though Flipper is an excellent starting point since it lets you use `react-native-reanimated` v2 with TurboModule support, frees you from the built-in Chrome debugging tools, gives you crash logs, and more. Just remember that you’ll need to create a new development build when you add a new module, or make judicious use of try/catch blocks to ensure you don’t throw an error.

## Keep Building From Here

This is just the start of what you can do with Expo’s development builds and Native Module support. Most Native Modules will work out of the box in a development build thanks to React Native’s autolinking, but if you do need custom changes to your `Info.plist` or `Manifest.xml` files (or even editing a `Podfile` like we did today), Expo can take care of that too as part of the build process. These [config plugins](https://docs.expo.dev/guides/config-plugins/) let you modify the plist and manifest without ejecting your app and are configured from within your `app.json`.

If you still run into issues, there’s an #EAS channel on the [Expo discord](https://discord.gg/4gtbPAdpaE) and the [Expo Forums](https://forums.expo.dev/) have an entire section dedicated to EAS.

There’s now an Expo community plugin for setting up Flipper in your Expo projects. The section on Flipper integration was updated to reflect this change.

This article was written for the Expo Blog and appeared with the title _Developing React Native with Expo and Flipper_. It's been reproduced here with permission.

Fence

{
  "build": {
    // ...
    "devclient": {
      "extends": "base",
      "releaseChannel": "default",
      "distribution": "internal",
      "developmentClient": true,
      "android": {
        "buildType": "apk"
      },
      "ios": {
        "simulator": true
      }
    }
  }
}


// App.tsx
import { connectToDevTools } from "react-devtools-core";
if (__DEV__) {
  connectToDevTools({
    host: "localhost",
    port: 8097,
  });
}


{
  "expo": {
    // ...
    "plugins": ["expo-community-flipper"]
}


Developing React Native with Expo and Flipper

```yaml
---
slug: tailwind-css-in-react-native
published: 2021-05-03T00:00:00.000Z
description: Tailwind's CSS classes in your React Native projects
changelog:
  - on: 2021-12-20
    note: I'm currently using [twrnc](https://www.npmjs.com/package/twrnc) which is an evolution of the tailwind-rn library. A pattern like `gust` is great for custom components, but right now, the React Native ecosystem almost always needs to pass style objects around.
---
```

React Native is very behind the web when it comes to UI libraries. There’s two likely reasons for this: CSS on the web is easy and the object known as `StyleSheet` in React Native is not.

At a fundamental level, the syntax of `StyleSheet` causes a lot of problems. It looks like CSS (the kind you’d use in React’s `style` prop), it acts like CSS (most of the time) just like you’d expect in a browser, but then you encounter one of dozens of scenarios where React Native takes the CSS specification and yeets it out the nearest window.

- Shadows are a custom object syntax instead of a conversion of `box-shadow`
- Random elements such as `ScrollView` introduce custom non-standard props such as `elevation`, but also only for specific platforms
- You get flexbox. Only flexbox. Everything flexes. Everything is boxes. Except for the `flex` property which has decided it is not actually `flex` as you’d expect but just a number that translates to a percentage. But not a useful number-to-percentage like `55` meaning `55%`. Instead, you get an alternate universe number that is expressed as a ratio based on the sum of all flex properties on sibling nodes. It’s a universe where `flex:1` means both `100%` and `50%` based on elements outside of its rendering tree. /rant

Yes, a lot of this will be fixed over time as React Native continues to improve on its style interpreter, but we are still converting from CSS to platform-specific layout calls. I don’t think we’ll ever reach parity, but I’d also like to avoid the programming equivalent of “hammering my thumb” every time I lay things out in a mobile app.

The truth is, what I want is something as easy as [Tailwind CSS](https://tailwindcss.com/) in React Native. If you haven’t tried Tailwind yet, you should. It’s trivial to make something look good, and it’s adaptable enough withstand design changes. In React Native, there's a few really solid options:

* **tailwind-rn**([github](https://github.com/vadimdemedes/tailwind-rn), [npm](https://www.npmjs.com/package/tailwind-rn)) is the OG of Tailwind in your React Native projects. It works by converting the Tailwind styles into JSON, which is memoized in your app on access. Because it tries to be only a translation layer between systems, complex behaviors such as breakpoints and React Native's Appearance are not supported out of the box.
* **tailwind-rn-gust** (_archived_ [github](https://github.com/jakobo/tailwind-rn-gust), [npm](https://www.npmjs.com/package/tailwind-rn-gust)) extends the `tailwind-rn` library by adding utilities for custom component creation. By introducing a React Component generator, it's possible to add additional props to turn "on" flags inside of a call to `tailwind-rn`'s style generator. _However, I wouldn't recommend this, as the components add an additional layer of complexity once you want to use `Animated.View` or other 3rd party components that want to leverage the `style` prop for stylistic behavior.
* **twrnc** ([github](https://github.com/jaredh159/tailwind-react-native-classnames), [npm](https://www.npmjs.com/package/twrnc)) Is what I'm currently using and it leverages [Tailwind's JIT Compiler](https://v2.tailwindcss.com/docs/just-in-time-mode) to remove the built steps inherent in other Tailwind-bridging systems. Out of the box, it uses React Native's hooks for figuring out screen sizes and appearance, making it easier to use normal Tailwind prefixes such as `lg:text-xl`.

Originally, this post focused on `tailwind-rn-gust`, but I think it's becoming more clear that until there's an official Tailwind for React Native, `twrnc` is going to be the truest-to-Tailwind experience you'll find on the platform.

Instead, here's how you'd accomplish something like a rich "press" interaction using `twrnc`. (You can also put both styles into a single `tw.style` call, but I find it easier to read leveraging the array syntax supported for multiple style objects.)

```jsx
<MyComponent style={({pressed}) => [
  tw`bg-red-500`,
  tw.style({
    "bg-blue-500": pressed
  })
]} />
```

The best thing about the `tw` helper is that it's built for generating `style` objects, meaning it'll work with Moti, Reanimated 2, and many other component libraries that focus on the `style` prop.

## Gust Archived
And so, with great alternatives out there, `gust` is archived. The [entire library](https://github.com/Jakobo/tailwind-rn-gust) is only 159 lines and is easy to port into your own existing React Native project if you need the features. However, until we see something like a native `className` in React Native, the `style` tag is going to be the default operating mode for rich styles, animation, and state based effects.


I'm currently using [twrnc](https://www.npmjs.com/package/twrnc) which is an evolution of the tailwind-rn library. A pattern like `gust` is great for custom components, but right now, the React Native ecosystem almost always needs to pass style objects around.

Tailwind's CSS classes in your React Native projects

<MyComponent style={({pressed}) => [
  tw`bg-red-500`,
  tw.style({
    "bg-blue-500": pressed
  })
]} />


A Guide to Tailwind CSS in React Native

```yaml
---
slug: running-expo-in-windows-subsystem-for-linux-wsl2
published: 2021-11-10T18:00:00.000Z
description: Windows, meet Expo in Linux
repost:
  url: https://blog.expo.dev/running-expo-in-windows-subsystem-for-linux-wsl2-425f6fd7838e
  text: This article was written for the Expo Blog and appeared with the title _Running Expo in Windows Subsystem for Linux (WSL2)_. It's been reproduced here with permission.
changelog: ~
---
```

If it runs in Node.js, it can run Expo. Even better, if it runs in Linux, you can take advantage of all the excellent React Native tools that may not be utilizing cross-platform utilities like `cross-env`. Since Windows 10 has support for Linux through a virtualized Windows Subsystem for Linux (WSL2), we can use that to run our Expo applications, build tooling, and more.

Getting everything working on WSL2 **does** have a few gotchas, which is why this guide can help you get up and running quickly and avoid some of the most common pitfalls (spoiler: it’s networking related).

# Overview

- Setting up WSL2
- Configuring `WSLHostPatcher`
- Alternative: Using Windows Firewall Rules
- Final considerations

# Setting up WSL2 for Expo Development

WSL2 gives you access to a fully featured Linux command line inside of Windows. While great cross-platform tools like `env-cmd` exist, not every tool we use in React Native development is Powershell-aware. Using WSL2 eliminates those problems entirely; it’s just Linux. Unless specified, all our commands will be in WSL2’s Linux environment.

****What You’ll Need for This Step****

1. Windows 10 or 11 (with or without the Windows Insider Program)
2. Windows Subsystem for Linux ([Instructions here](https://docs.microsoft.com/en-us/windows/wsl/install))

The first thing we’re going to need is both Expo CLI and EAS CLI in our WSL environment. From there, we can initialize our standard Expo app, just like a managed app. We’re using the Typescript template, but you can also opt for a vanilla JS experience.

    $ npm install -g eas-cli
    $ npm install -g expo-cli
    $ expo init expo-cdc-example
    $ cd expo-cdc-example
    $ yarn start

We’ll get our Expo QR code, but when we try to visit our developer page, we’ll end up at a 404. This happens because to our **browser**, `localhost `is referring to Windows, and Windows doesn’t know that those Expo requests need to be forwarded along to the WSL.

# Configuring `WSLHostPatcher`

Unless you have specific security concerns (such as exposing your Windows machine to the Internet), the fastest way to fix the port forwarding problems is with a utility called `[WSLHostPatcher](https://github.com/CzBiX/WSLHostPatcher)`. Built on the Windows Detours framework, it dynamically updates the bind & listen addresses for your WSL instances. We’re going to download the utility and run it every time our WSL instances starts. (Adjust appropriately for a non-BASH environment)

    $ cd
    $ mkdir wsl; cd wsl
    $ wget https://github.com/CzBiX/WSLHostPatcher/releases/download/v0.1.0/release.zip
    $ unzip release.zip
    # run WSLHostPatcher on every login
    $ echo "./wsl/WSLHostPatcher.exe" >> ~/.bashrc

Let’s close our dev console, along with any running `yarn` instances, and reload WSL. We’ll be greeted with `WSLHostPatcher` confirming it found and updated our WSL instance.

    Dll path: \\wsl$\Ubuntu\home\<yourname>\wsl\WSLHostPatch.dll
    Found 1 WSL host
    Patched 1

Give `expo start` a try now, and watch how your `localhost` request automatically finds its way to your Expo instance.

# Alternative: Windows Firewall Setup

One of the downsides to `WSLHostPatcher` is that it will bind your WSL instance to `0.0.0.0`. For most development scenarios, this is perfectly ok. If you have security concerns though, you can also use a Powershell script to forward specific ports to your WSL instance. This is a much longer setup, but uses the built-in Windows Firewall.

First, you’ll want to download the following script based on the excellent work of [@edwindijas on github](https://github.com/microsoft/WSL/issues/4150#issuecomment-504209723), and save it to `c:\scripts\wslbridge.ps1`. This script does a couple things.

1. Removes all existing WSL2 based routing rules
2. Creates new Outbound & Inbound rules on the Windows machine for your specified ports
3. Removes any existing proxies between Windows and your WSL instance
4. Creates a proxy from Windows to your WSL instance for all specified ports

```ps1
# [Configuration]
# All the ports you want to forward separated by coma
$ports=@(7700,8088,8089,19000);

# You can change the addr to your ip
# config to listen to a specific address
$addr='0.0.0.0';

# [Init]
$remoteport = bash.exe -c "ifconfig eth0 | grep 'inet '"
$found = $remoteport -match '\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}';
if( $found ){
  $remoteport = $matches[0];
} else{
  echo "The Script Exited, the ip address of WSL 2 cannot be found";
  exit;
}

$ports_a = $ports -join ",";

# Remove Firewall Exception Rules
iex "Remove-NetFireWallRule -DisplayName 'WSL 2 Firewall Unlock' ";

# adding Exception Rules for inbound and outbound Rules
iex "New-NetFireWallRule -DisplayName 'WSL 2 Firewall Unlock' -Direction Outbound -LocalPort $ports_a -Action Allow -Protocol TCP";

iex "New-NetFireWallRule -DisplayName 'WSL 2 Firewall Unlock' -Direction Inbound -LocalPort $ports_a -Action Allow -Protocol TCP";

for( $i = 0; $i -lt $ports.length; $i++ ){
  $port = $ports[$i];
  iex "netsh interface portproxy delete v4tov4 listenport=$port listenaddress=$addr";
  iex "netsh interface portproxy add v4tov4 listenport=$port listenaddress=$addr connectport=$port connectaddress=$remoteport";
}
```

Open up ****Task Scheduler**** and set up a task that will run the script on login, after a small delay. For reference, your task should look like the following:

![Create Task dialog box](https://user-images.githubusercontent.com/1795/146844508-fbd9cb3e-57e5-41b2-8cfc-d38873d9662e.png)
_Creating a task in the Task Scheduler_

![Task Triggers tab](https://user-images.githubusercontent.com/1795/146844535-fa52152a-575e-440f-826b-c8e8bfd18662.png)
_Setting a Trigger condition for our task_

![The Actions tab](https://user-images.githubusercontent.com/1795/146844565-cd926b31-0d6a-4cd3-a010-976a16e3c8e8.png)
_Task Action set to start the `wslbridge.ps1` script with the `-ExecutionPolicy Bypass` flag, allowing it to run with the necessary permissions_

Once configured, either on login or by running the script manually, Windows will automatically forward ports to WSL for you. From here, you can now run `expo start` from within WSL, and `localhost` will resolve as expected.

# Other Things You Can Do With WSL And Expo

The fun doesn’t stop at just accessing Expo’s developer tools. Because you can forward any port to WSL, that means you can access the Chrome Debugger, use `adb`, integrate Flipper, monitor with Wireshark, the list goes on! You’ll also be running your Expo builds from within Linux, meaning any build tooling will work just as it would on a Linux or Mac workstation.

It’s a great time to build React Native apps, and now it’s easier than ever on Windows.


This article was written for the Expo Blog and appeared with the title _Running Expo in Windows Subsystem for Linux (WSL2)_. It's been reproduced here with permission.

# [Configuration]
# All the ports you want to forward separated by coma
$ports=@(7700,8088,8089,19000);

# You can change the addr to your ip
# config to listen to a specific address
$addr='0.0.0.0';

# [Init]
$remoteport = bash.exe -c "ifconfig eth0 | grep 'inet '"
$found = $remoteport -match '\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}';
if( $found ){
  $remoteport = $matches[0];
} else{
  echo "The Script Exited, the ip address of WSL 2 cannot be found";
  exit;
}

$ports_a = $ports -join ",";

# Remove Firewall Exception Rules
iex "Remove-NetFireWallRule -DisplayName 'WSL 2 Firewall Unlock' ";

# adding Exception Rules for inbound and outbound Rules
iex "New-NetFireWallRule -DisplayName 'WSL 2 Firewall Unlock' -Direction Outbound -LocalPort $ports_a -Action Allow -Protocol TCP";

iex "New-NetFireWallRule -DisplayName 'WSL 2 Firewall Unlock' -Direction Inbound -LocalPort $ports_a -Action Allow -Protocol TCP";

for( $i = 0; $i -lt $ports.length; $i++ ){
  $port = $ports[$i];
  iex "netsh interface portproxy delete v4tov4 listenport=$port listenaddress=$addr";
  iex "netsh interface portproxy add v4tov4 listenport=$port listenaddress=$addr connectport=$port connectaddress=$remoteport";
}


Running Expo in Windows Subsystem for Linux (WSL2)

Because why learn 2 mobile languages when you can learn 3?