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.
Bundlers don’t implement module systems, they create scripts that emulate them. All any bundler does is reduce graphs. How is just implementation detail.
December 16, 2024 at 9:08 PM
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.
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`)
December 16, 2024 at 8:30 PM
(*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.
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.
December 16, 2024 at 8:27 PM
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.
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.
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.
December 16, 2024 at 4:05 PM
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.
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.
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.
December 16, 2024 at 3:50 PM
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.
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.
December 16, 2024 at 3:44 PM
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.
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.
December 16, 2024 at 2:18 AM
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.
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.
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.
December 16, 2024 at 1:48 AM
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.
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.
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]`)
(..which are also not respected in lazy comp, but the difference is pretty superficial - `[bytecode]` instead of `[native code]`)
December 15, 2024 at 9:49 PM
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]`)
(..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.
Tzvetan’s confirmed it’s a Hermes bug and Static Hermes works, though.
December 15, 2024 at 9:44 PM
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.
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…
Following up with Hermes as to whether that’s expected or a bug…
December 15, 2024 at 1:28 PM
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…
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?
December 8, 2024 at 11:02 PM
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.
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.
December 7, 2024 at 5:04 PM
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.
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.
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.
November 23, 2024 at 8:12 AM
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.
Remember when phones looked like the phone icon?
November 9, 2024 at 5:16 PM
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”.
If you don’t need to distinguish, just call them all “tests”.
November 9, 2024 at 4:59 PM
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”.
If you don’t need to distinguish, just call them all “tests”.
Event-source everything!
November 9, 2024 at 4:49 PM
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.
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.
November 9, 2024 at 4:32 PM
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.
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.
November 9, 2024 at 4:19 PM
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.
November 9, 2024 at 4:11 PM
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.
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.
November 9, 2024 at 4:09 PM
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.
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.