feat: Move virtualized lists to @react-native/virtualized-lists

[gabrieldonadel]

Summary

This PR moves VirtualizedList, VirtualizedSectionList, and its files to a separate package called @react-native/virtualized-lists located under packages/virtualized-lists as proposed on #35263

Changelog

[General] [Changed] - Move virtualized lists to @react-native/virtualized-lists package

Test Plan

1. Open the RNTester app and navigate to FlatList or SectionList page
2. Test virtualized lists through the many sections

Screen.Recording.2022-11-19.at.22.46.13.mov

[github-actions]

	Warnings
⚠️	🔒 package.json - Changes were made to package.json. This will require a manual import by a Facebook employee.

Generated by 🚫 dangerJS against b52ee19

[analysis-bot]

Platform	Engine	Arch	Size (bytes)	Diff
android	hermes	arm64-v8a	8,465,486	+264
android	hermes	armeabi-v7a	7,786,018	+262
android	hermes	x86	8,938,606	+269
android	hermes	x86_64	8,797,029	+272
android	jsc	arm64-v8a	9,650,929	+314
android	jsc	armeabi-v7a	8,385,393	+322
android	jsc	x86	9,713,150	+306
android	jsc	x86_64	10,190,292	+305

Base commit: 1fef376
Branch: main

[analysis-bot]

Platform	Engine	Arch	Size (bytes)	Diff
ios	-	universal	n/a	--

Base commit: 621969b
Branch: main

[pull-bot]

PR build artifact for b942261 is ready.
To use, download tarball from "Artifacts" tab in this CircleCI job then run yarn add <path to tarball> in your React Native project.

[pull-bot]

PR build artifact for 59fea61 is ready.
To use, download tarball from "Artifacts" tab in this CircleCI job then run yarn add <path to tarball> in your React Native project.

[gabrieldonadel]

@cortinico and @necolas, any thoughts on how to set up @react-native/virtualized-lists so react-native can locate this package when running CI tests using the template before we actually publish this to npm?

[hoxyq]

@cortinico and @necolas, any thoughts on how to set up @react-native/virtualized-lists so react-native can locate this package when running CI tests using the template before we actually publish this to npm?

Right now I am using Verdaccio and publishing necessary packages to local proxy. You can check how I did it in this commit.

I am currently working on first phase of monorepo project #34692, this should unblock you after we will merge my proposed changes

[NickGerleman]

Left some comments. Would also like some feedback from @necolas, but my sense is that we shouldn't extract to a separate package if both packages are still relying on each others private APIs. The package would not yet be reusable (even across different versions of RN), and the boundaries between the two are not enforced.

Copying the set of internal transitive dependencies to VirtualizedList so it doesn't rely on the internals seems like a potential start for migrating though, and it would allow us to shim between different platforms more easily in the VirtualizedList package.

[pull-bot]

PR build artifact for d689da0 is ready.
To use, download tarball from "Artifacts" tab in this CircleCI job then run yarn add <path to tarball> in your React Native project.

[pull-bot]

PR build artifact for 518cf03 is ready.
To use, download tarball from "Artifacts" tab in this CircleCI job then run yarn add <path to tarball> in your React Native project.

[gabrieldonadel]

@NickGerleman any updates on this? I know that this impacts a bunch of internal Meta code that references old VirtualizedList paths, but I was wondering, is there something I can help with?

[NickGerleman]

I haven't been able to dedicate much time to pushing this internally.

I spent a day a while back trying to find everywhere the previous structure was relied on, and I don't think we could safely ship the refactoring without staging it a bit more. Like, leaving old files around which forward to the new ones, so we can change product code more piecemeal.

It looked like a weekish of work dedicated to internal cleanup. Because it's all Meta code, we will need someone on our side to do the work, and figure out how to stage.

@hoxyq has worked through some similar headaches with lean core modules, and also has been looking at monorepo work. Might have a take on if there is a way we could stage this, where we could move to this structure in OSS without ripping up too much code out there.

[hoxyq]

I haven't been able to dedicate much time to pushing this internally.

I spent a day a while back trying to find everywhere the previous structure was relied on, and I don't think we could safely ship the refactoring without staging it a bit more. Like, leaving old files around which forward to the new ones, so we can change product code more piecemeal.

It looked like a weekish of work dedicated to internal cleanup. Because it's all Meta code, we will need someone on our side to do the work, and figure out how to stage.

@hoxyq has worked through some similar headaches with lean core modules, and also has been looking at monorepo work. Might have a take on if there is a way we could stage this, where we could move to this structure in OSS without ripping up too much code out there.

Will take a look at it next week

[facebook-github-bot]

@hoxyq has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

[necolas]

Like, leaving old files around which forward to the new ones, so we can change product code more piecemeal.

Isn't this what the PR does now? Maybe I missed something?

[gabrieldonadel]

Like, leaving old files around which forward to the new ones, so we can change product code more piecemeal.

Isn't this what the PR does now? Maybe I missed something?

I think the problem is that there are internal projects importing from specific internal paths like react-native/packages/virtualized-lists/Lists/CellRenderMask.js.

[NickGerleman]

Yeah, amazingly enough, there were even multiple cases of product code including the VirtualizedList utils helper to get a clamp() function for their own code lol.

I remember @lunaleaps was looking at what it would take to enforce the public boundaries more.

[hoxyq]

@gabrieldonadel

So I've made some changes both internally and in frames of this PR (exported in #36035), this is now accepted by @NickGerleman

Planning to merge this PR early next week 🤞

Meanwhile you can grep the difference between this PR and #36035 to check if everything is expected

There should be not that much, mostly re-exporting something, most of the work was made on the internal side

[gabrieldonadel]

Thanks for awesome work @hoxyq! Should I cherry-pick your commit to this PR?

[hoxyq]

Thanks for awesome work @hoxyq! Should I cherry-pick your commit to this PR?

No, this will be automatically resolved when I will merge internal changes, your commit will be merged in main branch together with mine and this PR will be closed and marked as merged

[facebook-github-bot]

@hoxyq merged this pull request in 2e3dbe9.