bit remove changes (soft delete)

[davidfirst]

Summary of a discussion I had with @ranm8 .

Background

We have a few challenges around deletion, some related to lanes, such as how you delete a component from a lane and export it.
Lane doesn't have versions (there is another discussion about this) so if we change the lane object and mark a component as deleted, bit status won't show it as such because there is no "modified" status to a lane.
Other use-case is when a component was created on a lane and there is a component with the same name in the original scope. We want the lane to replace the component it has currently with the one from the original scope. So even if we have the "versions" concept for lanes, this use-case is tricky, the lane object will have the same component in both, components and deleted components.

Suggestion

Component deletion, by default, will work similar to deprecation. The Version object will have aspect-data of a new aspect teambit.component/remove with removed: true. On the remote UI, we won't show these deleted components. On import (bit import scope-name/*) we won't bring these components.
In terms of implementation, when running bit remove, it'll delete the component directory from the filesystem, but not from .bitmap. On bit status, instead of showing an issue about missing-component-in-path, we'll show a new section of "deleted components", explaining that on the next snap/tag the component will be marked as deleted. Then, once exported, the remote is up to date with the deleted component.
A new flag --workspace for bit remove will remove the component from .bitmap as well, so it'll work the same as bit remove is working now.
bit remove --remote will remain intact, but we can explain that it's safer to use the bit remove locally, snap and export.

Use cases

After the remove (as discussed above - soft delete), the user creates a new component with the same name and export.
On the remote, we throw an error saying a deleted component exists with the same name. suggesting to import+merge/reset according to the following options:

1. if the deleted component has only snaps, not tags (this is the case when it's in a lane), then, we can combine the two components, although they have nothing in common. We can create a new snap-merge with two parents, one of the deleted component and one of the current component.
2. if the deleted component has a tag, and the newly created one has the same tag, we can't combine them. The local tags need to be remove by bit reset first and then the import+merge can take place.

@itaymendel , @GiladShoham , please let me know if you have feedback.

[itaymendel]

• we'll need to add warnings when import/install components that depend on deleted components
• are we cleaning artifacts from scope-registry
• let's reconsider the default... i think that a local delete is a more sensible default behavior for bit remove.

[davidfirst]

we'll need to add warnings when import/install components that depend on deleted components
Done for import. @GiladShoham , can you take care of the installation part? we probably need the same for deprecated component(?)

are we cleaning artifacts from scope-registry
Nope. we should leave everything on the remote scope the same.

let's reconsider the default... i think that a local delete is a more sensible default behavior for bit remove.
Agreed (by Ran as well). The default remained the same. The new flag is --soft.

[davidfirst]

Mostly implemented. See more details in the PR: #6363