...

[retyui]

...

[robhogan]

Stop spamming me, @retyui, please.

[retyui]

Oops, sorry Rob for the notifications! I'll ease up. Hope you're having a good day otherwise

[robhogan]

I think, fundamentally, matching on a relative import without the context that we're inside the react-native package is too prone to false positives.

Since this only affects react-native's own source (and forks), IMO it'd be better to fix there by rewriting those imports from relative paths to self-referencing package imports. I added self-referencing import support to Metro last week, not yet released, partly to facilitate that.

[rubennorte]

IMO it'd be better to fix there by rewriting those imports from relative paths to self-referencing package imports

This is very unidiomatic tbh and we actually have lint rules to prevent this.

Can we not know the path of the module being transformed to detect we're inside react-native?

[robhogan]

IMO it'd be better to fix there by rewriting those imports from relative paths to self-referencing package imports

This is very unidiomatic tbh and we actually have lint rules to prevent this.

Yeah I don't love it either 😅. It's not idiomatic, and it'd be a bad idea in general to import via a barrel file - this is a bit of a special case as Metro transforms the import away but it is still ugly. To solve for consumers of RN other than Meta it could be a pre-publish rewrite rather than something that lives in source.

Can we not know the path of the module being transformed to detect we're inside react-native?

Potentially, yeah - the projectRoot-relative path is a cache-safe transform input. It's not so easy to cover using RN directly from source in that case though.

Another ugly option is to guess that we're inside RN based on the copyright header or @oncall react_native.

Or, invent an explicit compiler hint and annotate the import.