new CLI argument to run against entry points more convenient

[michaelbe812]

(After this PR is merged)

We can pass entryPoints as CLI arguments like this sheriff verify '{ 'app-i': 'projects/app-i/src/main.ts', 'app-ii': 'projects/app-ii/src/main.ts', }'

this is not really convenient and also really error prone

Suggested Feature

Given this entryPoints in a sheriff.config.ts:

  entryPoints: {
    'app-i': 'projects/app-i/src/main.ts',
    'app-ii': 'projects/app-ii/src/main.ts',
  },

We will be able to call sheriff verify like this: sheriff verify --entryPoints=app-i or with multiple: sheriff verify --entryPoints=app-i,app-ii.

Questions

Should we still support passing entryPoints via a serialized object ('{ 'app-i': 'projects/app-i/src/main.ts', 'app-ii': 'projects/app-ii/src/main.ts', }')?

If we drop this option we can also simplify the internal implementation.

However it would be a breaking change.
(only if in the meantime a release is created which includes this PR

TODO

• introduce entryPoints CLI arg
• verify that provided entryPoints exist
• remove the possibility to provide entryPoints as serialized Record

[rainerhahnekamp]

Here are my thoughts:

So I would use the command sheriff verify app-i. I don't see the need for --entryPoint. I also don't think that it should be possible to pass a serialized Record<string, string>.

What this PR should also include a fallback. In case the entryPoint is not known, Sheriff should interpret it as a filename.

[michaelbe812]

The benefit of --entryPoint would be that it makes the internal implementation easier because we can definately assume that the intention was tu run against entryPoint(s).

However I am totally fine by omitting the extra argument.

I assume that sheriff verify app-i,app-ii should be possible to run against multiple entryPoints, right?

[michaelbe812]

in scope of #199