Move CLI options to build params

[TheJaredWilcurt]

It seems really strange that there are settings that can only be set in the CLI. I think it makes more sense to have all settings in the build object inside of package.json.

Specifically, I'd like to be able to control things on a per OS level. Like what distribution output type to use (which for some reason you call a "target"??? even though the target should actually be the OS/Arch).

Here's an example of one possible implementation for the API:

{
  "scripts": {
    "start": "nw .",
    "dist": "build ."
  },
  "devDependencies": {
    "nw": "sdk",
    "nwjs-builder-phoenix": "^1.x.x"
  },
  "build": {
    "nwVersion": "latest",
    "nwFlavor": "normal",
    "concurrent": true,
    "mirror": "https://dl.nwjs.io/",
    "files": [ "**/*" ],
    "excludes": [
      "package-lock.json",
      "assets"
    ],
    "win": {
      "icon": "assets/icon.ico",
      "arch": [ "x86" ],
      "targets": [ "nsis7z" ]
    },
    "mac": {
      "icon": "assets/icon.icns",
      "arch": [ "x64" ],
      "targets": [ "zip" ]
    },
    "linux": {
      "arch": [ "x86", "x64" ],
      "targets": [ "7z" ]
    },
    "nsis": {
      "icon": "assets/icon.ico",
      "unIcon": "assets/unicon.ico"
    }
  }
}

Things in the top level of build are globally applied to all platforms (like arch or targets), but if the setting is also inside of a specific platform, then it overrides the global setting because it's more specific.

Doing this means saving a lot of time on builds because I only need to do 1 zip build instead of 4, 2 7z instead of 4, and 1 nsis7z instead of 4. meaning I'm doing 4 builds and not 12. Though if this causes breaking changes, I would also say go all in and rename targets to outputType or distributionType or something that makes more sense.

[TheJaredWilcurt]

After some more thought, I think it makes more sense to have tasks as an array of objects, rather than limiting the tasks to just the OS platform.

{
  "scripts": {
    "start": "nw .",
    "dist": "build ."
  },
  "devDependencies": {
    "nw": "sdk",
    "nwjs-builder-phoenix": "^1.x.x"
  },
  "build": {
    "nwVersion": "latest",
    "nwFlavor": "normal",
    "concurrent": true,
    "mirror": "https://dl.nwjs.io/",
    "files": [ "**/*" ],
    "excludes": [
      "package-lock.json",
      "assets/*",
      "dev-utils/*"
    ],
    "nsis": {
      "icon": "assets/icon.ico",
      "unIcon": "assets/unicon.ico"
    },
    "tasks": [
      {
        "platform": "win",
        "arch": "x86",
        "icon": "assets/icon.ico",
        "target": "nsis7z"
      },
      {
        "platform": "win",
        "arch": "x86",
        "flavor": "sdk",
        "icon": "assets/icon.ico",
        "target": "zip",
        "outputPattern": "${NAME}-${VERSION}-${PLATFORM}-${ARCH}--DEVBUILD",
        "excludes": [
          "package-lock.json",
          "assets/*"
        ],
      },
      {
        "platform": "mac",
        "arch": "x64",
        "icon": "assets/icon.icns",
        "target": "zip"
      },
      {
        "platform": "linux",
        "arch": "x86",
        "target": "7z"
      },
      {
        "platform": "linux",
        "arch": "x64",
        "targets": "7z"
      }
    ]
  }
}

With this approach, you could produce as many builds as you want of any combination of settings. A good use case of this would be to create a developer build in addition to normal builds that uses the SDK flavor instead of just normal.

[conceptualspace]

rather than move the options, i would argue that there is a use case for supporting both: CLI simplifies using variables as option values and fits into more diverse CI / build automation workflows

[conceptualspace]

and just to be clear, while i still like command line options for purposes of integrating with other tools, i do also agree with this proposal. it would in fact solve for my use case as well.