<?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 index.d.ts</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>5234fe38 - feature(cli): add custom inspector proxy based on `metro-inspector-proxy` (#21449)</title>
        <link>http://172.16.0.5:8080/history/expo/packages/@expo/cli/ts-declarations/metro-inspector-proxy/index.d.ts#5234fe38</link>
        <description>feature(cli): add custom inspector proxy based on `metro-inspector-proxy` (#21449)# WhyFixes ENG-7467Related #21265This is an initial draft to extend the CDP functionality of`metro-inspector-proxy`.# HowThe implementation is slightly wonky around the `ExpoInspectorDevice`.We want to reuse as much as possible from `metro-inspector-proxy`, butwe need to add stateful data per device.In order to achieve that, we generate a new class type, based on theuser&apos;s installed `metro-inspector-proxy`. This makes everything lessreadable but should include future updates in these classes.As for the `ExpoInspectorProxy`, to avoid having to do the same thing,we just wrap the whole inspector class and reuse what we can. The devicemap is &quot;linked&quot; within the original inspector proxy instance, making thedata available to all methods that need it.# Test PlanEnable this feature with `EXPO_USE_CUSTOM_INSPECTOR_PROXY=1`- [x] See tests for the actual CDP events we handle.- [ ] See tests on the &quot;bootstrapping code&quot; to create the inspector anddevices.# 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 `expo prebuild` &amp; EAS Build (eg:updated a module plugin).---------Co-authored-by: Evan Bacon &lt;bacon@expo.io&gt;

            List of files:
            /expo/packages/@expo/cli/ts-declarations/metro-inspector-proxy/index.d.ts</description>
        <pubDate>Wed, 08 Mar 2023 17:16:56 +0000</pubDate>
        <dc:creator>Cedric van Putten &lt;me@bycedric.com&gt;</dc:creator>
    </item>
<item>
        <title>33643b60 - feat(cli): auto setup typescript during start (#21475)</title>
        <link>http://172.16.0.5:8080/history/expo/packages/@expo/cli/ts-declarations/metro-inspector-proxy/index.d.ts#33643b60</link>
        <description>feat(cli): auto setup typescript during start (#21475)# Why- Some users are confused about how to use the fully automatedTypeScript setup. It currently runs when you run `npx expo start` in aproject with `tsconfig.json` or any TypeScript file in the project.- This change will run the TypeScript check continuously untilTypeScript is setup. This only applies to projects using Metro, andcurrently is only run in `npx expo start`, and the run commands (whenthe server is started in the current window, e.g. not headless mode).&lt;!--Please describe the motivation for this PR, and link to relevant GitHubissues, forums posts, or feature requests.--&gt;# How- Fork the `runServer` function from Metro into the CLI so we can accessthe Metro bundler instance directly.- Use Metro&apos;s native file watching to observe new TypeScript files beingadded to the project (within the observable files). This is fast andensures we don&apos;t accidentally block a thread that otherwise could&apos;vebeen used for bundling.- The TypeScript continuous check only runs once, if you removeTypeScript and add it back in the same process, then nothing happens.This is a performance optimization.- If TypeScript is enabled while the process is running, the user willnot be prompted to install, the packages will just install in theproject. Failures will be displayed in the running process, and no moreattempts will be made.- If TypeScript is detected on start then the existing system will beused and the continuous check will be skipped, this means projectsalready using TypeScript won&apos;t have any technical performance hit.&lt;!--How did you build this feature or fix this bug and why?--&gt;# Test Plan- In a project without TypeScript:  - `npx expo`  - `touch tsconfig.json` or `mv index.js index.tsx` or `touch foo.tsx`  - TypeScript is automatically installed for the project.  - `EXPO_NO_TYPESCRIPT_SETUP` voids this behavior- Added unit tests.&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 `expo prebuild` &amp; EAS Build (eg:updated a module plugin).---------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/ts-declarations/metro-inspector-proxy/index.d.ts</description>
        <pubDate>Sat, 04 Mar 2023 02:26:10 +0000</pubDate>
        <dc:creator>Evan Bacon &lt;bacon@expo.io&gt;</dc:creator>
    </item>
</channel>
</rss>
