CLI

The CLI package is a simple way for users to interact with some of the build/validation tooling. As new capabilities are added to the ecosystem, they may be exposed via this cli to use of use for developers.

Config

Config files are able to customize the behavior of the CLI commands without requiring args. Behavior specific to execution can leverage plugins, which can be composed together using presets. Full configs can also be shared using extensions.

To resolve a full configuration, the extension is taken as the base, the presets are applied in order, then local plugins. The format is similar to eslint, babel and other .rc/json/js based approaches.

Config files are searched using cosmiconfig, which will look for:

• a player property in package.json
• a .playerrc file in JSON or YAML format
• a .player.json, .playerrc.yaml, .playerrc.yml, .playerrc.js, or .playerrc.cjs file
• a player.config.js or player.config.cjs CommonJS module exporting an object

Example:

module.exports = {
  extends: "@my-scope/base",
  plugins: [
    "plugin-npm-package",
    ["some-plugin-with-config", { config: true }],
    {
      // Plugins can also be defined inline
      handler: () => {},
    },
  ],
};

Options defined via the CLI arguments will take precedence over the config files (for things that overlap).

Plugins

Plugins are the way to change runtime behavior of the CLI actions. This includes augmenting the behavior of the DSL compiler, language-service, and more.

Commands

• player dsl compile Compile Player DSL files into JSON after running TSC compiler against Typescript files

USAGE
  $ player dsl compile -i <value> [-c <value>] [-o <value>] [--skip-validation]

FLAGS
  -c, --config=<value>  Path to a specific config file to load.
                        By default, will automatically search for an rc or config file to load
  -i, --input=<value>   (required) An input directory to compile.
                        Any jsx/ts/tsx files will be loaded via babel-require automatically.
  -o, --output=<value>  [default: _out] Output directory to write results to
  --skip-validation     Option to skip validating the generated JSON

DESCRIPTION
  Compile Player DSL files into JSON after running TSC compiler against Typescript files

• player dsl validate Runs isolated TSC compiler on authored Player DSL Typescript files.

USAGE
  $ player dsl validate [-f <value>] [-c <value>]

FLAGS
  -c, --config=<value>  Path to a specific config file to load.
                        By default, will automatically search for an rc or config file to load
  -f, --files=<value>...  A list of files or globs to validate

DESCRIPTION
  Runs isolated TSC compiler on authored Player DSL Typescript files.

• player json validate Validate Player JSON content

USAGE
  $ player json validate -f <value> [-c <value>]

FLAGS
  -c, --config=<value>    Path to a specific config file to load.
                          By default, will automatically search for an rc or config file to load
  -f, --files=<value>...  (required) A list of files or globs to validate

DESCRIPTION
  Validate Player JSON content

• player dependency-versions check Checks for @player-ui/@player-tools dependency version mismatches and issues warnings/solutions accordingly

USAGE
  $ player dependency-versions check [-c <value>] [-v] [-p] [-i <value>]
FLAGS
  -c, --config=<value>     Path to a specific config file to load.
                           By default, will automatically search for an rc or config file to load
  -i, --ignore=<value>...  Ignore the specified pattern(s) when outputting results. Note multiple patterns can be passed
  -p, --path               Outputs full path to dependency
  -v, --verbose            Give verbose description
DESCRIPTION
  Checks for `@player-ui/@player-tools` dependency version mismatches and issues warnings/solutions accordingly
  Consider the following:
  - The interpretation of TOP-LEVEL and NESTED dependencies is as follows:
  a. TOP-LEVEL dependencies only have one 'node_modules' in their path
  b. NESTED dependencies have more than one 'node_modules' in their path
  - `@player-ui/@player-tools` dependencies are fetched not only from inside the 'node_modules' at the top of the repository in which it is run but also from 'node_modules' in sub-directories.
  For example, if you have some 'node_modules' inside of a 'packages' folder that contains `@player-ui/@player-tools` dependencies, then these will also be fetched.
  The display of such dependencies also depends on the first bullet point.