phil 🫠
@kitten.sh
👋 strangely typed
• dev tools at @expo.dev 𝝠
• n+1 semi-archived GraphQL/TS/React(Native) projects 🗻
• urql, gql.tada (prev. dank mono, css-in-js shenanigans)
• 🐙 https://github.com/kitten & https://tangled.sh/@kitten.sh
• dev tools at @expo.dev 𝝠
• n+1 semi-archived GraphQL/TS/React(Native) projects 🗻
• urql, gql.tada (prev. dank mono, css-in-js shenanigans)
• 🐙 https://github.com/kitten & https://tangled.sh/@kitten.sh
clearly, whoever is tasked with writing these is running out of ways to say "lol no"
October 3, 2025 at 6:44 PM
clearly, whoever is tasked with writing these is running out of ways to say "lol no"
hm does blocking the dev of the app block the app though? not that it matters much since they can just create more accounts & apps, but basically just seeing an app and a big install button first feels bad here 😅
September 24, 2025 at 12:49 AM
hm does blocking the dev of the app block the app though? not that it matters much since they can just create more accounts & apps, but basically just seeing an app and a big install button first feels bad here 😅
there's also an experiment that allows you to auto-resolve issues with duplicate native module dependencies or hoisting conflicts (monorepos rejoice!) ✨
flip one flag, and Expo Autolinking also applies its autolinking decisions to Expo's metro bundling
flip one flag, and Expo Autolinking also applies its autolinking decisions to Expo's metro bundling
September 12, 2025 at 6:34 AM
there's also an experiment that allows you to auto-resolve issues with duplicate native module dependencies or hoisting conflicts (monorepos rejoice!) ✨
flip one flag, and Expo Autolinking also applies its autolinking decisions to Expo's metro bundling
flip one flag, and Expo Autolinking also applies its autolinking decisions to Expo's metro bundling
Expo Autolinking is more transparent and consistent now. Both expo-doctor and the expo-modules-autolinking verify command can now consistently highlight issues with duplicate dependencies 👀🕵️
(the screenshot here shows the output that Bluesky gets for debugging, for example)
(the screenshot here shows the output that Bluesky gets for debugging, for example)
September 12, 2025 at 6:34 AM
Expo Autolinking is more transparent and consistent now. Both expo-doctor and the expo-modules-autolinking verify command can now consistently highlight issues with duplicate dependencies 👀🕵️
(the screenshot here shows the output that Bluesky gets for debugging, for example)
(the screenshot here shows the output that Bluesky gets for debugging, for example)
Autolinking will also work much more like "what you see is what you get" with transitive linking for RN modules, better duplicate detection, better hoisting conflict detection, etc
this also means we can safely expand our official package manager support!
this also means we can safely expand our official package manager support!
September 12, 2025 at 6:34 AM
Autolinking will also work much more like "what you see is what you get" with transitive linking for RN modules, better duplicate detection, better hoisting conflict detection, etc
this also means we can safely expand our official package manager support!
this also means we can safely expand our official package manager support!
a lot of implicit deps chains are fixed. One example, if something else depends on Metro that won't break Expo in any case anymore
(Pictured: @expo/metro-config's deps graph. And yes, we're also working on reducing deps continuously, more news on that soon)
(Pictured: @expo/metro-config's deps graph. And yes, we're also working on reducing deps continuously, more news on that soon)
September 12, 2025 at 6:34 AM
a lot of implicit deps chains are fixed. One example, if something else depends on Metro that won't break Expo in any case anymore
(Pictured: @expo/metro-config's deps graph. And yes, we're also working on reducing deps continuously, more news on that soon)
(Pictured: @expo/metro-config's deps graph. And yes, we're also working on reducing deps continuously, more news on that soon)
really have to finish a new blog post,
so instead, I of course took @arrowtype.bsky.social's amazing Recursive font, made some tweaks (rough sketch still due to some import issues), threw it in my blog that hasn't seen new posts for 5yrs and updated its colour scheme
priorities ❤️
so instead, I of course took @arrowtype.bsky.social's amazing Recursive font, made some tweaks (rough sketch still due to some import issues), threw it in my blog that hasn't seen new posts for 5yrs and updated its colour scheme
priorities ❤️
August 24, 2025 at 6:21 PM
really have to finish a new blog post,
so instead, I of course took @arrowtype.bsky.social's amazing Recursive font, made some tweaks (rough sketch still due to some import issues), threw it in my blog that hasn't seen new posts for 5yrs and updated its colour scheme
priorities ❤️
so instead, I of course took @arrowtype.bsky.social's amazing Recursive font, made some tweaks (rough sketch still due to some import issues), threw it in my blog that hasn't seen new posts for 5yrs and updated its colour scheme
priorities ❤️
no matter the app, you really can't escape the inevitable @freezydorito.lol for long 😂😂
August 21, 2025 at 7:06 PM
no matter the app, you really can't escape the inevitable @freezydorito.lol for long 😂😂
maybe i care less about spending time with and on graphql these days, but i do care about numbers going up 📈
February 13, 2025 at 10:05 AM
maybe i care less about spending time with and on graphql these days, but i do care about numbers going up 📈
pretty exciting, since, as this is based on TS' getDefinitionAtPosition's own implementation, this gives us a lot of confidence in its robustness.
All I removed were edge cases we don't encounter, and just using TS symbols also mean we can limit the amount of AST nodes we end up resolving to
All I removed were edge cases we don't encounter, and just using TS symbols also mean we can limit the amount of AST nodes we end up resolving to
November 4, 2024 at 12:23 PM
pretty exciting, since, as this is based on TS' getDefinitionAtPosition's own implementation, this gives us a lot of confidence in its robustness.
All I removed were edge cases we don't encounter, and just using TS symbols also mean we can limit the amount of AST nodes we end up resolving to
All I removed were edge cases we don't encounter, and just using TS symbols also mean we can limit the amount of AST nodes we end up resolving to
eventually I'll have to find some time to work more on GraphQLSP (the TS plugin used by gql.tada for LSP integration)
currently, we use TS' getDefinitionAtPosition a lot to get to GraphQL document references, but I've got a PR that looks to switch this to a symbol-based implementation instead
currently, we use TS' getDefinitionAtPosition a lot to get to GraphQL document references, but I've got a PR that looks to switch this to a symbol-based implementation instead
November 4, 2024 at 12:20 PM
eventually I'll have to find some time to work more on GraphQLSP (the TS plugin used by gql.tada for LSP integration)
currently, we use TS' getDefinitionAtPosition a lot to get to GraphQL document references, but I've got a PR that looks to switch this to a symbol-based implementation instead
currently, we use TS' getDefinitionAtPosition a lot to get to GraphQL document references, but I've got a PR that looks to switch this to a symbol-based implementation instead
(small behind-the-scenes effort) the @expo.dev SDK 52 will shed several old/unused npm deps
in future SDKs pre-bundling, more fixes, and external changes will help too
But overall, installing SDK 52 will already be faster than installing SDK 51 🚀
(npm graph side-by-side for comparison)
in future SDKs pre-bundling, more fixes, and external changes will help too
But overall, installing SDK 52 will already be faster than installing SDK 51 🚀
(npm graph side-by-side for comparison)
November 2, 2024 at 2:50 PM
(small behind-the-scenes effort) the @expo.dev SDK 52 will shed several old/unused npm deps
in future SDKs pre-bundling, more fixes, and external changes will help too
But overall, installing SDK 52 will already be faster than installing SDK 51 🚀
(npm graph side-by-side for comparison)
in future SDKs pre-bundling, more fixes, and external changes will help too
But overall, installing SDK 52 will already be faster than installing SDK 51 🚀
(npm graph side-by-side for comparison)
no judgement here right? but opening a UDP socket in Node seems to be a very reliable and portable way to get the preferred & public network route's IP address 😅
seems odd, but also(!) seems to work 🥲
seems odd, but also(!) seems to work 🥲
October 31, 2024 at 5:02 PM
no judgement here right? but opening a UDP socket in Node seems to be a very reliable and portable way to get the preferred & public network route's IP address 😅
seems odd, but also(!) seems to work 🥲
seems odd, but also(!) seems to work 🥲
my goal hence was to use Linux's usbhid driver (instead of a custom one) to re-use all of its logic while still applying mouse acceleration.
this can actually be done by shifting the mouse acceleration logic to an input handler. In an input handler we get to filter and modify events
this can actually be done by shifting the mouse acceleration logic to an input handler. In an input handler we get to filter and modify events
October 30, 2024 at 11:51 AM
my goal hence was to use Linux's usbhid driver (instead of a custom one) to re-use all of its logic while still applying mouse acceleration.
this can actually be done by shifting the mouse acceleration logic to an input handler. In an input handler we get to filter and modify events
this can actually be done by shifting the mouse acceleration logic to an input handler. In an input handler we get to filter and modify events
However, this didn't really work for some of mice. turns out, the leetmouse driver is a full USB driver — taking the default Linux's usbhid driver's place
This is very low level, but has a big drawback. It loses out on Linux working around many USB devices' quirks, so some devices just don't work
This is very low level, but has a big drawback. It loses out on Linux working around many USB devices' quirks, so some devices just don't work
October 30, 2024 at 11:47 AM
However, this didn't really work for some of mice. turns out, the leetmouse driver is a full USB driver — taking the default Linux's usbhid driver's place
This is very low level, but has a big drawback. It loses out on Linux working around many USB devices' quirks, so some devices just don't work
This is very low level, but has a big drawback. It loses out on Linux working around many USB devices' quirks, so some devices just don't work
For Linux, there's "Leetmouse" (which is a fork of another older project) adding the same functionality. And recently someone forked this project to add a GUI to this mouse driver, called "Yeetmouse" (yes, it's a fork of a fork 😄)
They added a really nice Imgui interface to configure the driver
They added a really nice Imgui interface to configure the driver
October 30, 2024 at 11:44 AM
For Linux, there's "Leetmouse" (which is a fork of another older project) adding the same functionality. And recently someone forked this project to add a GUI to this mouse driver, called "Yeetmouse" (yes, it's a fork of a fork 😄)
They added a really nice Imgui interface to configure the driver
They added a really nice Imgui interface to configure the driver
Rawaccel is quite interesting. it's a Windows driver that can be configured with a small UI that, instead of keeping a constant mouse sensitivity, makes sensitivity configurable. It changes depending on the current input speed, usually accelerating mouse movement the faster you move your mouse.
October 30, 2024 at 11:41 AM
Rawaccel is quite interesting. it's a Windows driver that can be configured with a small UI that, instead of keeping a constant mouse sensitivity, makes sensitivity configurable. It changes depending on the current input speed, usually accelerating mouse movement the faster you move your mouse.
parsing & printing in @0no-co/graphql.web is now even speedier (faster than graphql.js)
📄 recap: graphql.web is a spec-compliant lib for GraphQL parsing, printing, and visiting for client-side GraphQL clients and a drop-in replacement. It ships by default with urql
📄 recap: graphql.web is a spec-compliant lib for GraphQL parsing, printing, and visiting for client-side GraphQL clients and a drop-in replacement. It ships by default with urql
April 2, 2024 at 1:02 PM
parsing & printing in @0no-co/graphql.web is now even speedier (faster than graphql.js)
📄 recap: graphql.web is a spec-compliant lib for GraphQL parsing, printing, and visiting for client-side GraphQL clients and a drop-in replacement. It ships by default with urql
📄 recap: graphql.web is a spec-compliant lib for GraphQL parsing, printing, and visiting for client-side GraphQL clients and a drop-in replacement. It ships by default with urql
so far this weekend, I’ve been working on updating my colour scheme. picked out 20 colours (16 ansi and 4 UI colours) while my colour blindness was sabotaging me. This was exhausting
March 30, 2024 at 10:29 PM
so far this weekend, I’ve been working on updating my colour scheme. picked out 20 colours (16 ansi and 4 UI colours) while my colour blindness was sabotaging me. This was exhausting
please make this stop 🥲 please let this be an easy fix
March 2, 2024 at 1:06 PM
please make this stop 🥲 please let this be an easy fix