Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MultiRoot Workspace support #663

Merged
merged 17 commits into from
Feb 28, 2025
Merged

Conversation

filip131311
Copy link
Collaborator

@filip131311 filip131311 commented Oct 25, 2024

  1. This PR refactors how we handle the appRoot to allow for changing it in runtime. To make sure that the app root is unified across all the components we now store it in project.ts and move all objects dependent on appRoot to project as well. We listen for launchConfiguration changes and restart everything dependent on appRoot after it changes.

  2. We refactor how appRoot is detected:
    after analyzing the old approach that was using workspace.findFiles we realized that on more elaborate setups it took almost 2 seconds to traverse all of the workspace directories. To combat that we introduce a new findAppRootCandidates implementation that takes only a couple of ms in most setups.
    note: the new function is not perfectly equivalent to the old one as it removes a check if node_modules contains react-native it is done on purpose as it has a following drawbacks:

  • generetes false positives as some not applications directories (e.g. libries) might contain react-native in its node modules,
  • mono repositories might generate false positives at top level depending on the implementation
  • it requires searching through node_modules which are usually quite large
  • it is not even that useful, because it requires node_modules to be installed and first time users could encounter problems if we relied on this check.
  1. Additionally we enhance the Lunch Configuration View to allow the user for selecting the appRoot from the list.

How has dis been tested?

  • Run the mono repo with 2 application and switch between them.

  • Run react-native-svg repo and select test apps in it

  • Run react-native-reanimated repo and select test apps in it, additionally check if cashes are stored properly after switching between applications.

  • To benchmark the findAppRootCandidates I added the following code to at the end of the activate function in the extension:

const start = performance.now();

  await findAppRootFolder() 

  const end = performance.now()

  Logger.debug("My benchmark result:", end-start);

note: that the benchmark make sens only if you don't have appRoot set in launchConfiguration.

Results for react-native-reanimated repository:

old new
1479.05 ms 1.27 ms

Copy link

vercel bot commented Oct 25, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
radon-ide ✅ Ready (Inspect) Visit Preview 💬 Add feedback Feb 28, 2025 0:42am

@kmagiera kmagiera marked this pull request as draft October 29, 2024 08:28
filip131311 added a commit that referenced this pull request Nov 22, 2024
This PR add a possibility to reboot the reboot device, metro and
devtools processes without triggering clean build. It was previously
only possible by closing and reopening the IDE panel itself.

This also will provide necessary functionality for  #663

### How Has This Been Tested: 

- run an application and pick "Reboot IDE" option from reload dropdown
menu
kmagiera added a commit that referenced this pull request Dec 16, 2024
This PR changes a way we manage build caches. Previous approach was
dependent on current vscode workspace, which led to build caches not
being accessible when switching from working in the root of the
workspace to the root of the application (or doing the same in reverse).
The new approach saves this data in global storage, and adds a appRoot
identifier to the cache key.

This PR is a dependency for #663

### How Has This Been Tested: 

- Open a project in the root of the workspace and run some application
that is part of it in the IDE.
- Open IDE in the root of that application and see if the build cache is
loaded.
- repeat the proces in reverse
- open an application that had a build made before this change and check
if migration process works as expected

Verify that the build cache migration work:
- Build project without these changes
- Open the same project with no changes but with the new version of
extension – expect the cache hit for native build

---------

Co-authored-by: Krzysztof Magiera <[email protected]>
@filip131311 filip131311 marked this pull request as ready for review December 19, 2024 15:41
@filip131311 filip131311 requested a review from kmagiera December 20, 2024 09:40
@filip131311 filip131311 changed the title Draft of MultiRoot Workspace support MultiRoot Workspace support Dec 20, 2024
@filip131311 filip131311 force-pushed the @Filip131311/FixMultiRootWorkspaces branch from 0f8aa95 to 76da6d1 Compare January 17, 2025 14:45
@filip131311 filip131311 force-pushed the @Filip131311/FixMultiRootWorkspaces branch from 76da6d1 to 9317a59 Compare January 17, 2025 14:57
Comment on lines +204 to +206
export async function isNodeModulesInstalled(
manager: PackageManagerInfo,
appRoot: string
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe PackageManagerInfo should hold the appRoot instead? Isn't the "Package Manager Info" only relevant in the context of a specific "app root"?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if it ever gonna be useful in the future, but it is not. You theoretically can call nmp install in any workspace directory and with the correct setiting all of the will be installed

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, but PackageManagerInfo contains the information on which package manager should be used which, if I understand correctly, depends on the contents of appRoot, no? Can't changing the app root could cause the selected package manager to change?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It sometimes could, but it is unlikely, but at the end of the day the important question is not if those values are sometimes related but if there might be the situation ever of changing only one of them and as I have written above there might be

Copy link
Contributor

@jwajgelt jwajgelt Feb 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But this is exactly what I mean -- if you change the appRoot you probably want to recreate the PackageManagerInfo, right?
The way it's written right now, you supply them separately, so you may provide the "wrong" PackageManagerInfo, i.e. one unrelated to the passed appRoot.

)
.then((item) => {
if (item === openLaunchConfigButton) {
commands.executeCommand("workbench.action.debug.configure");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this the correct action for this? For me it opens the command palette, while I'd expect it to open our launch configuration menu (where I can actually select the app root).

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know why it opens a command palet for you, It works for me and opens a correct configuration file, In the future i would love to migrete to opening our configuration panel but i feel like it is not stable enough yet.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could you run this comand from command palet and see what happens? do you use cursor or vs code?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

VSCode.
It's probably because I don't have the file in that project.

@filip131311 filip131311 merged commit 9b4ab57 into main Feb 28, 2025
4 checks passed
@filip131311 filip131311 deleted the @Filip131311/FixMultiRootWorkspaces branch February 28, 2025 12:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants