component and workspace configuration

[GiladShoham]

This issue is a task list for many tasks required for an extension to be able to use bit's config (both from workspace and components)

This is related to some of the tasks in issue: #2455

checklist

below you can find more details for some of the tasks

implementation

• Generate bit.jsonc instead of bit.json / package.json (bit prop)
• support comments in bit.jsonc
• support new format of workspace config
• make sure old configs are working
• do not generate package.json in component folder by default
• handle old package.json in component folder
• write merged config into capsule's package.json
• provide a new (better) API of components config to use in extensions
• implement a new workspace config extension
  • extensions skeleton
  • provide an API for workspace config
  • provide a way for an extension to load its config from the workspace
• provide a way for an extension to write configs to a component
• when ejecting config of component write in the generated package.json only props overridden by the user (do not write entries created by extensions, since if we do, they will become user overrides next tag which we don't want)
• make sure import --conf is working
• support overriding both the main dist and main source file
• add overridden dependencies to generated package.json (what we got from eject conf)
• merge overridden deps from the packge.json with component final dependencies

tests

• make sure all old tests are pass
• create a way to run the old tests using the old bit.json / package.json

details

• support new format of workspace config - the workspace config top level will have a schema, schema version, variants, and workspace extensions configs.
  variants are similar to the old overrides property we used to have (each entry inside is a component glob pattern)
• handle old package.json in a component folder - we should identify it's an old package.json created before harmony and not treat its props as overrides like new ones.
  We can do it by identity there is bit.env path in the file
• provide a way for an extension to write configs to a component - this will be done by exposing a way to register to an event. this event will be triggered during the component loading, and the extension can return an object with configs. this config will be merged into the component configs and will be available for other extensions later.
• implement a new component config strategy - the strategies are as follows (top is the stronger)
  • user overrides (props user write in the component package.json)
  • user overrides in workspace config (the old propagation rules in case of multiple matching stay the same)
  • config provided by extensions (there is no order guarantee, an extension might override another extension config)
• bit calculated configs (the core is actually the same is extension since it's built from extensions, but the extension run later, so they will override) this include calculation from both fs and models
  the merge will be done based on a top-level property similar to do something like object.assign(bit config, extension config, workspace config, component package.json)
  But some of the props will have special merge strategies:
  for example, dependencies (all types - runtime / dev and peer) can be overridden completely by the user if he specify those props in the package.json (this will eliminate completely the automatic dependency definition by bit)
  but there are special props (exact names TBD) - dependenciesOverrides.(runtime,dev,peer), values from there will be merged into the dependencies instead of compleltly override them. those props also support the "+" and "-" symbols to add/remove dependencies). for example if an extension wants to add react in v16.0.0 he will return:

{ 
  dependenciesOverrides: {
    runtime: {
      "react": "16.0.0"
    }
  }
}

• provide a new (better) API of components config to use in extensions - this config will be based on the consumer component, and all the merge strategies described above
• write an updated config into the components package.json in a capsule - when creating a capsule for a component we should write it's package.json after merging all the configs. this will create different package.json in the capsule and in the component folder in workspace. they are not represent the same thing anymore. the package.json in the workspace component folder represent a way to modifiy specific configuration. while in the capsule it represent the final configuration for consuming / running.
• support overriding both the main dist and main source file - since the package.json in component dir and capsule are different, the main prop is representing the main dist file as written in the capsule (which means it won't be written by default when ejecting config) unless the user override it himself. the main source file will be under @component.main
• add overridden dependencies to generated package.json (what we got from eject conf) - similar to the main prop, the deps/devDeps/peerDeps represents the final deps from the capsule, so they won't be written by default.
  In case the user overrides them, he overrides all of them.
  If he wants to use the + / - to modify the deps it will be under @component.dependences, @component.devDependences, @component.peerDependences

[ranm8]

@GiladShoham please remind me, why do we need extensions property in variants?

[GiladShoham]

We discuessed it.
It's a way to separate between extensions and some other props I want to add to the package.json
we talked about changing it to have prefix instead.
There is a task about it: #2536
please suggest a prefix there

[ranm8]

See my comment there. I do think we can use valid package names instead. Happy to hear your thoughts.

[itaymendel]

irrelevant