Improve control over component metadata

[itaymendel]

This feature might be strongly related to #2456

The metadata Bit keeps on each component is limited to specific cases. This makes it hard to let developers decide what's the metadata they want to keep on each component. Moreover, we often find ourselves wanting to add more metadata on components for features in Bit, and then we have to come up with an entire flow of how to keep relevant data for the feature and let the end-user control it manually or using APIs.

Bit should streamline the way it keeps and manages component metadata for the benefits of features in Bit and how to more flexibility towards user-specific configurations and annotations.

Benefits

Using a streamlined mechanism for controlling component metadata we can provide better control for component-level features like:

• Annotating internal and public components.
• Better control over license.
• Adding any arbitrary params to a component.

Proposal

$ bit variant <component regex> --set foo bar // set param 'foo' with value 'bar' for component(s)
$ bit variant <component regex> --get foo     // get value of param 'foo' component(s)

• Use --set several times to pass multiple params (like curl).
• rename bit variant to bit param ?
• We can add features like --list etc and extend functionality in the future.

Open questions

Handle new components

When creating or tracking new components, folks should be able to set these params to the components as part of the creation of a new component. This can be possible by supporting a new flag for bit add and bit create called --set:

$ bit add path/to/folder --set foo bar // sets param 'foo' with value 'bar' for new component.

However, as only when tagging a component Bit keeps a config for it, there's no place to keep the param. A possible workaround is to use the .bitmap file, as its an index file for Bit, when tracking components, and keep params there. Later, when the component is tagged, Bit can remove the params from .bitmap and keep them as part of the component (we can also use the same flow to add the default variants from the workspace config to each new component).
Another option is to introduce a similar index to the local scope itself and let Bit maintain it there.

Blacklist for params

Similar to override and variants, there are several params that users should not be allowed to modify using this flow (mainly name and version). We'll probably need to use the same limitation in this flow as well.

Native support for objects and arrays

While it's going to be very easy for managing strings, if people will try it for more complicated objects, it's not going to be fun. To be honest, I'm not sure if we need to handle it right now, but it's possible that we should have a way to natively support more complicated value types (for example - ability to set a param as an array and then have the ability to add/remove from it).

API to configure variants for workspace?

$ bit variant <component regex> --workspace --set foo bar // set param 'foo' with value 'bar' as a workspace variant
$ bit variant <component regex> --workspace --get foo     // get value of 'foo' from workspace variants

It's possible to use this syntax to support configuring the workspace itself. While this adds a few cases to figure out - it can be a nice addition to the command.

[GiladShoham]

Not relevant anymore