Improve export command to support implicit exports and better upstream management

[itaymendel]

Some of the flag and property names are TBD and might be changed as we progress with the development of the feature.

Context

bit export is lacking the support of managing and syncing a single component between many collections. This means that it is very hard to:

1. Export the same components to several collections ("forking").
2. Sync component changes in several collections (managing upstreams).
3. No way to run an implicit bit export command that will export each component to the correct collection (need to manually define to which collection which component will be exported to).
4. No way to include component's dependencies with a 'fork'.

To resolve it there are several features and improvements to implement.

Support defaultCollection in workspace configuration

To allow implicit exports for staged components that have never been exported, Bit needs to support a defaultCollection property for a workspace. It is not mandatory but will improve user experience.

{
  "bit": {
    "defaultCollection": "<string>"
  }
}

Add a list of upstream collections to component

A component should contain an ordered list of objects representing the remote upstreams. Each item on the list should have:

1. url - the location of the remote collection. if upstream was resolved in hub_domain use it as a url.
2. name.
3. date.

Workspace should contain the current upstream that the component is synced to.

To allow implicit exports for components that were already exported, the workspace should distinct a specific collection as the current collection to sync the component with.

1. If I exported a component to any non-default collection, the component should still remain staged, unless I specifically asked Bit to change the current-collection (more on that later).
2. If I change current after export and set it to the location I have exported the component to, the component is still staged. But when I try to export again, Bit will figure out that the component was already exported, and unstage it.

Show current in bit show

bit show is the main API for providing data on a component. It should support showing the workspace data about current collection.

Update export command synopsis.

$ $ bit export [--eject] [--include-dependencies] [--set-current-upstream] [--force] [<scope> [<component id patterns>...]]

Options

--eject

After export, removes the exported components and install them as node modules using npm/yarn.

--set-current

Ensure the component's remote scope is set according to the target location.

--force

Ignore prompt about moving components to another scope.

<scope>

The "remote" scope that is the destination of the export operation.

<component id patterns>

Component name, ID or a glob-pattern. Bit to parses it to get the component IDs to export.

--include-dependencies

Include the component's dependencies as part of the export to the remote scope.

Examples

$ bit export

Works just like bit export <scope>, where <scope> is current component's scope.
If no scope is defined for a component, triggers a message to add a scope (upstream) to the component.

Implicit export only applied for staged components.

$ bit export current

Without additional configuration, exports each component to their current scope (upstream).
If no scope is defined for a component, triggers a message to add a scope (upstream) to the component.
If a workspace has default-scope defined and a component does not have a scope, sets the default-scope as an upstream for the component, and export.

Implicit export only applied for staged components.

$ bit export current foo/bar

Exports component foo/bar to its current scope. If a component has no scope defined, and a workspace has default-scope defined and a component does not have a scope, sets the default-scope as an upstream for the component, and export.

$ bit export moon foo/bar

Add the scope moon to foo/bar as an upstream (scope) and exports component to it.
If the component does not have any upstream defined, sets moon as the current scope.
If the component has other upstreams defined, the command does not change the current scope.

$ bit export moon *

Add the scope moon to all components as an upstream (scope) and exports component to it.
If the component does not have any upstream defined, sets moon as the current scope.
If the component has other upstreams defined, the command does not change the current scope.

If there's a mix of components that some of them might move to another scope, trigger a message asking user to approve (or use --force).

$ bit export sun foo/bar --set-current-upstream

Exports foo/bar to sun and set the workspace to use sun as the current (default) scope for the components.

Possible future options

--code-mod

Update the exported component's import and require statements (if found) to the scope they are being exported to.

--eject-dependencies

Eject component dependencies and installs them as node modules. Does not mean Bit ejects itself. Only relevant for directly imported components that are dependencies.

[davidfirst]

All improvements are implemented on #1954, except the "Possible future options".
A few changes from the description above.

1. The flag --set-current-upstream has changed to --set-current-scope.
2. The workspace config defaultCollection has changed to defaultScope.
3. The scopes list is shown by running bit show with (an existing) --detailed flag. I figured that for most cases this won't be relevant.
4. Added a new flag --all to include also non-staged components. Without this flag, when running bit export <remote> or bit export <remote> *, it affects only staged components.

[Tallyb]

can we rename --code-mod to --redirect? code-mod can do any change.

[davidfirst]

@Tallyb , not sure about --redirect, it doesn't tell me about the code change.
Maybe --codemod-scope-change?

[GiladShoham]

maybe --codemode-scope-name?

[Tallyb]

--rename-scope?

[davidfirst]

@Tallyb , not sure that --rename-scope is clear enough about changing the source code, which is something that Bit has never done before.
I believe that users will interpret rename-scope to an internal Bit change of the component and not their code.

[GiladShoham]

@Tallyb I agree with @davidfirst . rename scope is a bit confusing because it's not say anything about code changes.

[Tallyb]

--codemod -> --rewire-imports / --refactor-imports : changes the import statement for components that are exported to a new collection to depend on the component in the new scope.

[GiladShoham]

I'm renaming it to --rewire-scope

[itaymendel]

resolved as part of b15