Extension point should come after processing other members

[mgiuca]

The steps for processing a manifest defines an extension point that allows proprietary and externally specified members to be inserted and have post-processing steps defined.

However, it is Step 3 of the algorithm, occurring before any of the standard manifest members are post-processed, which means any custom logic is unable to make use of the final value of other manifest fields, such as scope. I think it should come last (i.e., between current Step 14 and 15).

For example, I am currently working on a share_target extension shown here: [preview] [pull request]

The post-processing step for share_target requires the final version of scope. If I were to define share_target in the manifest spec itself, it would have its post-processing step performed somewhere between Step 7 and 15. Since I am defining it in an external spec, I need to add it at the extension point, which is before scope's post-processing steps. I guess I could run the post-processing the scope member algorithm redundantly from my spec, but that seems unwieldy.

Is there any harm in moving the extension point to the end of this algorithm?

[marcoscaceres]

I'm ok with us moving it... the idea was to prevent people overriding standard behavior. If that becomes a problem, we can modify this to be:

const defaultValues = processManifest();
const extendedValues = processExtensions(defaultValues);
const finalValue = {...extendedValues, ...defaultValues};
return finalValue;