iiinova — where your digital self keeps evolving

Rob Hogan @robhogan.dev · 16/12/2024

Indeed - I’m not fully sure what it would even mean for a bundler to natively support ESM, or CJS for that matter. There are no ESM bundles (yet) Bundlers don’t implement module systems, they create scripts that emulate them. All any bundler does is reduce graphs. How is just implementation detail.

040

Rob Hogan @robhogan.dev · 16/12/2024

(*experimentalImportSupport was designed for runtime perf in opinionated codebases, and doesn’t yet support circular dependencies or `export let`)

020

Rob Hogan @robhogan.dev · 16/12/2024

Yep. Although neither is really “native” (that’s on the engine), both are just Babel transforms. The difference is mostly that in the latter case Metro can tell the difference between imports and requires, for things like Expo tree shaking, conditional resolution, and inlining.

140

Rob Hogan @robhogan.dev · 16/12/2024

As a tooling guy I have a lot of sympathy for this - even in Metro, Flow was a pain point in SWC experiments. But DX for us is about users building apps. Ease of bring-your-own-toolchain isn’t a DX goal. If you use a framework it’s a non-issue, if you author a framework, build on the common core.

120

Rob Hogan @robhogan.dev · 16/12/2024

The other possibility is something like JS0, essentially a communicable, specced intermediate. The problem with the status quo is we talk about pre-compilation with no agreed target (Node LTS, browserslist, ES5?). Most pre-compiled node_modules wouldn’t run in Hermes, so we have to compile again.

120

Rob Hogan @robhogan.dev · 16/12/2024

Yeah, I think we’re probably just talking about different time horizons, ultimately I expect precompilation to go away because I think it’s been a crutch we ideally wouldn’t need, but I don’t think it’ll be soon - just signs we’re moving that way.

120

Rob Hogan @robhogan.dev · 16/12/2024

It matters if the pre-compilation loses information or adds cruft, which it generally does. Besides bundles being smaller and faster, publishing source is easier, and it’s more hackable and debug friendly. With Bun+Node supporting TS directly and web still build reliant, we might see more of it.

130

Rob Hogan @robhogan.dev · 16/12/2024

Libraries shipping Flow/TS source might turn out to be well-placed for Static Hermes. In general, there are good arguments for preserving information. Pre-compiled is rarely optimally compiled. It’s just not the way the ecosystem has gone.

160

Rob Hogan @robhogan.dev · 15/12/2024

Yep, especially because “hide source” and “sensitive” are a thing. (..which are also not respected in lazy comp, but the difference is pretty superficial - `[bytecode]` instead of `[native code]`)

030

Rob Hogan @robhogan.dev · 15/12/2024

Before compilation would make sense as an explanation, but even invoking the function before calling its toString doesn’t help. I suspect Hermes is looking in the wrong place (original AST?) for the directive. Tzvetan’s confirmed it’s a Hermes bug and Static Hermes works, though.

150

Rob Hogan @robhogan.dev · 15/12/2024

Ok, sniped 😅! This turns out to be because `show source` doesn’t work under lazy Hermes compilation if the input is >64KB, the preemptive compile threshold (hence appearing to work under Fast Refresh but not initial load). Following up with Hermes as to whether that’s expected or a bug…

240

Rob Hogan @robhogan.dev · 08/12/2024

Would love to improve things here - what kind of errors do you run into? Cross web/mobile or between native platforms?

120

Rob Hogan @robhogan.dev · 07/12/2024

RN receives and accepts more community contributions than React/GQL, partly because it’s a bigger surface, but it has a lively community. DevTools though was built in the open by a dedicated team at Meta over many months. That was the only way we were going to ship the ground-up rewrite it needed.

130

Rob Hogan @robhogan.dev · 05/12/2024

React Native 0.77 is stabilising with the second RC out yesterday. Do give it a try, let us know how you get on! github.com/facebook/rea...

0243

Rob Hogan @robhogan.dev · 23/11/2024

That’s basically how I was taught it. It’s the empty product. Multiplying no things gets you the multiplicative identity, same as summing no things = additive identity.

120

Reposted by Rob Hogan

Addy Osmani @addyosmani.bsky.social · 10/11/2024

Sometimes the best engineering happens when you’re just tinkering, free from expectations and deadlines.

1835951

Rob Hogan @robhogan.dev · 09/11/2024

Remember when phones looked like the phone icon?

020

Rob Hogan @robhogan.dev · 09/11/2024

Maybe tweak that - choose labels based on the distinctions you need to make - eg if you have some expensive tests that only run nightly, label them accordingly. If you don’t need to distinguish, just call them all “tests”.

010

Rob Hogan @robhogan.dev · 09/11/2024

Event-source everything!

000

Rob Hogan @robhogan.dev · 09/11/2024

That’s a shortcoming of the testing framework IMO - they’re not true e2e tests if they depend on details your user doesn’t act on/observe. If you had an AI testing framework that let you write “tap the most obvious button” -> “see confirmation page” you’d be a lot closer to e2e for human UIs.

030

Rob Hogan @robhogan.dev · 09/11/2024

The distinctions can be meaningful - for example any change that breaks an e2e test is by definition semver major.

130

Rob Hogan @robhogan.dev · 09/11/2024

Eg: testing a React component may be a unit test if you’re writing an app, but an e2e test of the react library itself.

130

Rob Hogan @robhogan.dev · 09/11/2024

IMO: Unit tests test an indivisible piece of the software under test. An integration test is any test that isn’t a unit test. e2e tests are the subset of integration tests that deal with user input to user-observable output/effect. All relative to where the boundaries of your software are.

2100

Reposted by Rob Hogan