π«Ά any time
15.06.2025 12:00
π 3
π 0
π¬ 0
π 0
π«Ά any time
@joshuakgoldberg.com sorry for the no-reply on the repo. Is there anything you need changed in the repo?
I think I still have access to it, maybe you do too? Happy to do some maintenance if thatβs required. But, for bigger things, it prob need to wait for after some conferences π
Right now, I donβt have a lot of bandwidth. But what needs to be done on this repository?
This is what Google does all the time. Even in their Flutter conferences they promote apps from big companies by just saying their name, not that only 1 division of that big corp in 1 single country uses Flutter. All while most other countries of the same corp use something else.
Oh man, so much to come still! We can work on so many other parts of the universal story now.
π
I added the `EAI_AGAIN` error to the offline detection (when fetch is failing). github.com/expo/expo/pu...
For normal offline errors, we automatically switch to offline mode with a warning that it did. See: github.com/expo/expo/bl...
As the `βoffline` flag mentions, we ping the API to get a list of known dependencies that we use to check if you might be running incompatible `expo-*` packages for SDK 50.
We also catch known offline related issues, unfortunately the EAI_AGAIN is a DNS error but doesnβt indicate you are offline.
Syntax trees shouldnβt have to be compiled or evaluated. Itβs usually a token based lexer that only represents the written code through an accessible interface. Hence itβs the only way to mutate code in a stable manner.
Preferably all mods that are required for a platform have a proper way to do a mod using some sort of AST/CST. Thatβs the only way to make things stable
The noop disables dangerous mods for the platform. Otherwise it would error out. Dangerous mods were a βif itβs not implemented, there is still _a_ way to do somethingβ but itβs not recommended and it could be unstable.
Thatβs why I just disabled it.
Fun fact, both React Native Test App (RNTA) - github.com/microsoft/re... - and react-native-tvos (github.com/react-native...) are using config plugins! Any other out-of-tree platform can adopt it as well.
You know it's a banger when my first words are "sorry, not sorry".
Listen in to an in-depth conversation about React Native debugging from both Alex hunt and me! We have come a long way but have much more to come.
Its better to go for a plugin approach. Even though we don't have a plugin system for Metro configs. Using specialized functions to modify configs lowers the risk a little bit, and adds code-as-documentation to users configs. E.g
module.export = withNativeWind(config, { .. });
Easy to pull out too
I disagree with the "merging configs", I don't think thats a good idea in any way. Merging configs can override so many things without users realizing. That's why we discourage using `import { mergeConfig } from 'metro-config'`.
Itβs the same for Metro config. You often accidentally overwrite some configuration that breaks something in unexpected ways
Ok
π
Itβs not about the size, itβs what you can do with 5.5β screenshots
Yeah, I just used the default template and added Tldraw. If you are on SDK 52, DOM components work out of the box.
github.com/byCedric/tld...
This is slick!
Canβt wait until we lower the dependency count even more β€οΈ
Having access to the full ecosystem of React (and -Native) libraries truly unlocks possibilities. Even when βjustβ using a web view.
Iβm still amazed how powerful DOM components are. I mean, try implementing an infinite drawing canvas on web, iOS, and Android in under 5 minutes.
With DOM components you actually can.
