Override any package.json key in overrides

[itaymendel]

Description

A developer should have better control over the component's package.json and its contents. At the moment the ability to so is limited due to the fact that overrides only allows for modifications on the dependencies, peerDependencies and devDependncies fields. So if a developer wants to have a bin for the component - it is not possible.
This hurts the component's flexibility.

Describe the solution you'd like

overrides should allow setting ANY key/value pair in the component's package.json. Bit should then take all values and set them to the calculated package.json.

Blacklisted keys

There are some keys that the developer must not be able to override:

• name
• version
• main

Input validation to package.json keys

Bit has to make sure that the calculated package.json will be a valid one. Meaning that if a specific key is used (for example bin) - its type should be according to the specs (perhaps using something like this?).
In case the outcome for a component is not valid, Bit should not allow tagging the component and prompt with a message saying that the key is not set according to the package.json specs.

Merging values of similar keys

The overrides feature supports merging for dependencies, peerDependencies and devDependencies in case that the same component fit more than one overriding rule. Bit should keep this behavior (and still ensure that the more specific rule wins).

In cases where a merge is not possible (the value in either override rules is not of the same type) - the more specific rule should "win".

Adding keys outside of the package.json specs

Bit should allow developers to add any key they want, even if its not in the specs, as long as the output is still a valid json file. Additionally, all merge rules should support it as well.

[davidfirst]

Implemented on #1890 as described above.
Added e2e-tests and unit tests for different scenarios.
The validation is done by the API of https://github.com/gorillamania/package.json-validator as suggested.
To the blacklisted keys I have added also bit.
The merge between a more general and a more specific rule is done only when both are objects. Otherwise, the specific value wins.

[itaymendel]

@KutnerUri @qballer now we can implement benv as a component :))))))))

[KutnerUri]

@itaymendel - so cool!!
where are the docs for it?

[itaymendel]

it's not yet GA, so docs are not public... But it should look like this (in your project's package.josn):

"bit": {
    "overrides": {
        "<component id>": {
            "bin": /* your bin object here */
        }
    }
}

If you want to play with it, you should clone Bit and build from master.

[KutnerUri]

SOO NICE!

[Tallyb]

@itaymendel @GiladShoham: @davidfirst probably wiser would be to wrap in an object to avoid collisions with npm attributes. E.g. if npm decide to add "exclude" as a valid package property.

[GiladShoham]

@Tallyb but we don't want to wrap it because there are features on the root keys.
for example, bin will only work on the root.

[Tallyb]

overrides: {
"someRule/*": {
   "env": {...},
   "devDeps": {},
   "exclude": true,
   "package": {
        "bin": "...",
       "something": {}
}
}
}

alternatively, you should put all internal variables (propagate, exclude) on some

"_options": { ...}

[GiladShoham]

@Tallyb. Ok understand. Make a total sense.. We will change it.

[GiladShoham]

@Tallyb Can you open a new issue for this improvement? if we keep it here we will forget it.