cedric
@cedric.dev
Doing stuff with 𝝠 @expo - Preparing for Launch - Creator of need.review - Don't let your memes be dreams - Something of an 😇 investor myself
@joshuakgoldberg.com sorry for the no-reply on the repo. Is there anything you need changed in the repo?
May 19, 2025 at 10:09 PM
@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 🙈
May 19, 2025 at 10:08 PM
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?
May 19, 2025 at 8:09 PM
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.
January 14, 2025 at 4:26 PM
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.
I added the `EAI_AGAIN` error to the offline detection (when fetch is failing). github.com/expo/expo/pu...
fix(cli): add `EAI_AGAIN` DNS service errors to offline detection by byCedric · Pull Request #34014 · expo/expo
Why
Someone on Bluesky mentioned running into this error. EAI_AGAIN indicates that the DNS service returned a server-side error. Although it doesn't indicate the user is offline, it does preven...
github.com
January 8, 2025 at 11:17 AM
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...
github.com
January 8, 2025 at 10:39 AM
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.
We also catch known offline related issues, unfortunately the EAI_AGAIN is a DNS error but doesn’t indicate you are offline.
January 8, 2025 at 10:36 AM
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.
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.
January 3, 2025 at 9:52 AM
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
January 2, 2025 at 9:57 AM
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.
That’s why I just disabled it.
January 2, 2025 at 9:55 AM
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.
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.
react-native-test-app/plugins at trunk · microsoft/react-native-test-app
react-native-test-app provides an app for all supported platforms as a package - microsoft/react-native-test-app
github.com
December 10, 2024 at 7:08 PM
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.
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
module.export = withNativeWind(config, { .. });
Easy to pull out too
December 5, 2024 at 11:24 AM
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
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'`.
December 5, 2024 at 11:22 AM
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
December 5, 2024 at 10:35 AM
It’s the same for Metro config. You often accidentally overwrite some configuration that breaks something in unexpected ways
It’s not about the size, it’s what you can do with 5.5” screenshots
November 6, 2024 at 9:22 AM
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...
github.com/byCedric/tld...
GitHub - byCedric/tldraw-dom-components: Unlock the full React ecosystem on native
Unlock the full React ecosystem on native. Contribute to byCedric/tldraw-dom-components development by creating an account on GitHub.
github.com
November 4, 2024 at 10:27 AM
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...
github.com/byCedric/tld...