search

vrchat-community / creator-companion

The Entry Point for Making Things in VRChat
https://vrchat.com/home/download
53 stars 354 forks source link

[FEATURE] Remove unused packages from project when resolve[FEATURE] #493

Open anatawa12 opened 1 month ago

anatawa12 commented 1 month ago

Is your feature request related to a problem? Please describe. If we removed some package from dependencies for projects that is controlled over VCS, the VPM client does not remove packages resolve after checkout.

Describe the solution you'd like Keep a list of vpm-managed packages somewhere that is not controlled by VCS in the project and remove packages that are on the list but not in vpm-manifest.json on resolving packages.

Describe alternatives you've considered Just removing all embedded packages in the Packages but it would cause projects for developing packages to lose their project contents.

Additional context

Detailed Description for the feature

I think it might be a good idea to use Library folder to store the list of packages that are managed by VPM because the Library folder is a folder that VCS should not control. The VPM is heavily using JSON, so I think it's a good idea to use JSON for the list. Therefore, I'm calling the list Library/vpm-managed-packages.json but it's just a suggestion.

When installing a package, VPM Client will add the package to Library/vpm-managed-packages.json file and when removing a package, VPM Client will remove the package from the Library/vpm-managed-packages.json file.

On each VPM Related operation, VPM Client can add all installed packages in the vpm-manifest.json to the Library/vpm-managed-packages.json file and remove packages do not exist in the Packages folder from the Library/vpm-managed-packages.json file.

When resolving packages, VPM Client will remove packages that are in Library/vpm-managed-packages.json but not in vpm-manifest.json.

I think this feature will help developers to keep their project clean and tidy.

Compatibility considerations with vpm clients that are not supporting this feature

If a VPM Client that does not support this feature adds a package to the vpm-manifest.json but does not add the package to the Library/vpm-managed-packages.json. However, this does not cause any practical problems because the package is in the Packages folder, and it's easy to fix this situation by adding packages to Library/vpm-managed-packages.json with VPM Clients that support this feature.

If a VPM Client that does not support this feature removes a package from the vpm-manifest.json but does not remove the package from the Library/vpm-managed-packages.json. This also generally causes no problems because the package is not in the Packages folder, and it's easy to fix this situation by removing packages from Library/vpm-managed-packages.json with VPM Clients that support this feature.

However, if the user removed a package with VPM Client without this feature and then added the package again as non-VPM-managed. This makes non-VPM-managed package to be recognized as VPM-managed package by VPM Clients that support this feature. This can happen when the user wants to develop the already installed package. User manually remove package directory, remove entry from vpm-manifest.json, and re-install the package by git clone. This can be relatively rare since git clone creates folder named repository name, not package name (id). But I think we should document this behavior carefully and suggest to not clone the package repository with same folder name as the package id.

orels1 commented 1 month ago

That is an interesting request. The current "sync" handling between vpm-manifest, the lock within it, and the packages on disk has definitely been less reliable than we would like. And I like this suggestion of keeping track of all the packages actually locally installed by VPM-based tooling (since we cant just nuke everything that isnt in the lock, node_modules style).

Thank you for the suggestion