Rob Hogan

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.

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

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.

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.

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.

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.

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.

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.

"show source" is not always respected under lazy compilation · Issue #1583 · facebook/hermes Bug Description Lazy compilation does not respect "show source", so [function].toString() fails to provide useful output. This is observable under React Native, typically when loading a bundle in d...

github.com/facebook/her...

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]`)

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.

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…

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

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.

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...

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.

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

Remember when phones looked like the phone icon?

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”.

Event-source everything!

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.

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

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.

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.

I hear this is where tech twitter went

The new React Native DevTools are wild.

No additional tools are required to drill down into your components like this.

WOW 🔥

bsky is the best react native app I’ve ever seen

Hi folks! 👋

⚛️🚇🦋