dojo / cli

:rocket: Dojo - command line tooling.
http://dojo.io
Other
25 stars 34 forks source link

Support extending dojorc configuration #295

Closed agubler closed 5 years ago

agubler commented 5 years ago

Enhancement

In Dojo 6 we added support for using a custom dojorc file with the CLI. This opened many possibilities for creating multiple configurations with tweaked options simply by using the --dojorc option.

Unfortunately this requires all common configuration to be duplicated across each dojorc file, we should support extending dojorc files.

JamesLMilner commented 5 years ago

What level of config merging would we like to do here? I think top level property merging is an obvious requirement i.e.

// .dojorc
{
  "extends": "./base-dojorc",
  "build-app": {
    "legacy": false,
    "build-time-render": {
       // stuff
     }
  }
}

// .base-dojorc
{
  "pwa": {
    "manifest": {...},
  }
}

// Results in:

{
  "extends": "./base-dojorc",
  "build-app": {
    "legacy": false,
    "build-time-render": {
       // stuff
     }
  }
  "pwa": {
    "manifest": {...},
  }
}

However, if we have matching top level properties like so, how would we expect this to behave?

// .dojorc
{
 "extends": "./base-dojorc",
  "build-app": {
    "legacy": false,
    "build-time-render": {
       // child properties
     }
  }
}

// .base-dojorc
{
  "build-app": {
    "legacy": true,
    "build-time-render": {
        // child properties
     }
     "proxy": {
        // child properties
    }
}

// Results in?

Here the question is should it completely replace the whole build-app top level property, or should it try and merge it's child properties? If so, do we merge all the way down the tree or do we stop at the first level of children?

To me a sensible output for this situation would be :

{
 "extends": "./base-dojorc",
  "build-app": {
    "legacy": false,
    "build-time-render": {
       // .dojorc "build-time-render" properties
     }
    "proxy": {
        // .base-dojorc "proxy" properties
     }
  }
}