phil 🫠

@gabimoncha @expo @swmansion .@chrfalch is fixing up the buildFromSource propagation quirk here: github.com/expo/expo/pull…

@gabimoncha @expo @swmansion hm, at a glance, this doesn't necessarily strike me as a cache issue. Assuming `buildFromSource: ["react-native-worklets"]` then this kind of looks like precompiled isn't gating on the dependency chain and opting out dependents

is there a way to clear @expo eas cloud cache? i've used precompiled modules together with @swmansion rnrepo and because of a worklet patch that wasn't yet synced, the build step reused reanimated but compiler worklets which seems to be a big nono because they need to be compiled together not separately using --clear-cache when doing local build fixed this after the new worklet version was saved by rnrepo, but not on eas cloud cc @hirbod @_philpl

@gabimoncha @expo @swmansion but re. the native cache, i'm not sure how these interact but I guess in some cases we do assume some form of ABI stability. Not sure how that comes into play if not both of them are marked as build from source, but can check internally

@gabimoncha @expo @swmansion if by worklets patch you mean the bundle mode, it's not something I want to step in on, but in its current implementation we can't/don't support that. We have some internal APIs and changes planned out to support this fully but that said currently it's not "timing-stable"

@Baconbrix @SpaceXAI some might say there were signs haha 🤠🚀 congrats! 🥳

Honored to announce that I’ve joined @SpaceXAI! 🚀 I believe this team can do for intelligence what SpaceX did for rockets and the internet, I'm grateful and humbled to contribute to it. If you have feedback on Grok, Grok Build, or the APIs; I'm all ears!

@techstack404 @bidah @expo it's closer than some might thing, but yes, agreed, but either way, I just take a bit of issue with "Expo Web" is dead (as said in other replies) because it implies an "end" rather than a "start"

@_philpl @bidah @expo Expo's web target gives the impression it's the equivalent but it's not. I don't doubt you guys will figure that out eventually, expo is awesome wouldn't choose anything else. And I can't wait for web to be a viable option for serious web applications.

announcement: @expo web is dead. Expo will never tell it to you so I will save you the trouble. There is no need making code reuse work everywhere these days. The gap from native to web will always be there. Avoid it at all cost. That said universal apps have a new resurgence these days. How it goes now? You need to embrace the power of the web with frameworks like Vite. Add a thin agent skill to be invoked after a web feature development is done asking to build the feature again for mobile with the same internal API. That is the way.

as in, to summarise, coming into React Native with the expectations of it being a cross-platform tool (I'll build for Android, and it'll work on iOS, or any other two platforms, including web) isn't a path of the right expectations or automatic success from that doesn't follow though that Expo Web is dead. it's a unique platform with unique requirements

that then also includes opinions such as React Native Web or React Strict DOM (or using neither) Expo Router won't in the future pull in RNW automatically anymore. meaning, we're actually moving towards removing opinions because "ios/android -> web" with the same code from scratch isn't bound to work out for the majority of people

@bidah @expo dead implies that it was alive, rather it's developing. feedback on that is important to me/us, to be clear, but implying "Expo Web" is dead ignores progress from release after release on the pure web experience

@_philpl @expo I said people inside Expo would disagree so I get it. But if Expo web can't create a better app than Vite, Next.js, or Tanstack Start its has always been dead to make the point even more clear.

@satya164 that and eventually expo-router (& other expo libs) shouldn't by default pull in React Native Web. imho, from that perspective, the statement is just nonsensical to me I can get behind "cross-platform including web makes no sense" but anything beyond is just kind of a weird take

I don't get this statement. You still have the full power of Web when using Expo Web, just like you still have the full power of Android & iOS with native code. Nothing locks you to using React Native Web only APIs. Dropping down to using DOM APIs directly is perfectly viable, and I already do a lot. Why spend extra tokens just because?

so "Expo Web is dead" is just disappointing clickbait that misses the mark. Instead, Expo will become a great web framework, regardless of other platforms, and in general, the simple idea here is: You shouldn't have to choose another framework for your web apps. (which drives any speculation on death ad absurdum)

@bidah @expo "Expo Web" as a target is just that, our ambition to make Web a great target for Expo. That explicitly means: - you won't necessarily use React Native Web in the future - you may not want react-strict-dom - you may not want to go "all the way" with a x-platform wrapper code

@satya164 i'd consider galvanised square steel beams exceptionally load-bearing

No Claude, there's nothing I consider "load-bearing". I don't even know what that means.

@GroundControl pnpm virtual global stores 🤠 (although even w/o cloned files will help)

macOS: 30 GB Applications: 45 GB Documents: 18 GB node_modules across 20 git worktrees: 847 GB someone who is good at computers please help me manage my storage my family is dying

@cantstopnyxia @birch_js @_colinhunt @expo oh shit i do?

@_philpl @birch_js @_colinhunt @expo stfu, you work at expo too

Sooo, what can I do with these… If only Argent from @swmansion could drive physical iOS devices, I’d design a nice wall mounted charging and data hub and self host some real device testing across many devices 🤔

@cantstopnyxia @birch_js @_colinhunt @expo lmao

@birch_js @_colinhunt And why tf do I help someone that works @expo, They are doing RAM eating shit, 500MB ram to render text.

@jmeistrich do you ever plan to not have a new release lined up before we meet up?

I just released LegendList 3.3.3, the result of running some deep performance analysis with Sol. It's less blanky while scrolling fast, positions don't jump anymore, less overhead with many item types, better onStartReached/onEndReached. The apps I tested look much better! 🎉

there's probably something that went wrong with the 57 upgrade you're attempting. Try running expo-doctor first to see if there's obvious issues. I'd temporarily switch to an app.config.js since a ts file can temporarily hide some issues The `--full` config command runs a few more things. I think we might not be outputting the full error here so you're seeing the error from a fallback (which might be a separate issue on our end)

@expo my builds been failing since yesterday with “failed to read the app config file with `expo config`” running npx expo config locally reads the file just fine but on EAS it is failing. help help help…need to get this project off my hands!