package.json: add lint-plugin script

[atiratree]

Faster and easier linting for plugin development. Usage:

yarn lintme packages/kubevirt-plugin

• this was created as reaction to kubevirt: add lint scripts #1826

[atiratree]

/retest

[mareklibra]

Isn't this over-complicated?
IIUC, we are trying to reuse previous lint rule from individual packages.
And the only thing preventing us from reusing the existing top-level lint script is the folder . specified there.
The simplest solution is to introduce a new generic rule without the the folder, so specialized rule can reuse it by calling it with one extra parameter (the folder). Sort of generic-lint rule or similar. This approach seems to me much more clear at the first glance, so without the need to dig into another .ts file to get understanding what the linter does.

Please note, there is already related PR: #1411

[christianvogt]

Adding a new eslint script without a path would be very flexible and solve your use case:
` "eslint": "eslint --ext .js,.jsx,.ts,.tsx --color",

Then do:
yarn eslint packages/kubevirt

or be more specific to test a single file:
yarn eslint **/MyFile.tsx

[atiratree]

yes that is much easier (although without autocompletion)

• added generic eslint script

[atiratree]

/retest

[atiratree]

/retest

[atiratree]

/retest

[atiratree]

Tests passed. Can we proceed with this one?

[vojtechszocs]

And the only thing preventing us from reusing the existing top-level lint script is the folder . specified there.

@mareklibra Right, that's the drawback of ESLint CLI when compared to Jest - ESLint requires an explicit path to work with, while Jest falls back to current work dir if the path isn't specified. In essence, this makes the reuse of ESLint scripts/commands harder.

Adding a new eslint script without a path would be very flexible and solve your use case:
"eslint": "eslint --ext .js,.jsx,.ts,.tsx --color",

LGTM, but note that this causes the project-specific eslint script to over-shadow the actual binary ./node_modules/.bin/eslint (shouldn't be a problem, though).

[vojtechszocs]

/lgtm

[atiratree]

LGTM, but note that this causes the project-specific eslint script to over-shadow the actual binary ./node_modules/.bin/eslint (shouldn't be a problem, though).

Renamed to lintme. Let me know if somebody comes up with a better name

[atiratree]

/test e2e-aws

[vojtechszocs]

I'd prefer to go with @christianvogt's suggestion:

Adding a new eslint script without a path would be very flexible and solve your use case:
"eslint": "eslint --ext .js,.jsx,.ts,.tsx --color",

Please replace lintme with eslint. All developers should use the same eslint script for unified experience.

The fact that eslint script in package.json over-shadows ./node_modules/.bin/eslint delegation (yarn run) is not a problem, so no need to come up with alternative script names like lintme.

[vojtechszocs]

This should be yarn eslint .

[vojtechszocs]

/assign

[atiratree]

reverted back to eslint

[atiratree]

/test e2e-aws-console-olm
/test e2e-aws-console

[vojtechszocs]

/lgtm

cc @christianvogt

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: suomiy, vojtechszocs

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• frontend/OWNERS [vojtechszocs]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment