as we want to avoid requiring npm et al for every build, this is also
effectively vendoring all in, so easier to avoid supply-chain attacks
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
instead linting all files in the main thread, use worker threads
for that (4 by default) and add the '-t' switch to able to control that
a basic benchmark of eslint of pve-manager showed some performance
gains:
Benchmark #1: Current
Time (mean ± σ): 6.468 s ± 0.116 s [User: 9.803 s, System: 0.333 s]
Range (min … max): 6.264 s … 6.647 s 10 runs
Benchmark #2: 2Threads
Time (mean ± σ): 4.509 s ± 0.106 s [User: 12.706 s, System: 0.530 s]
Range (min … max): 4.335 s … 4.674 s 10 runs
Benchmark #3: 4Threads
Time (mean ± σ): 3.471 s ± 0.033 s [User: 16.390 s, System: 0.630 s]
Range (min … max): 3.431 s … 3.542 s 10 runs
Benchmark #4: 8Threads
Time (mean ± σ): 2.880 s ± 0.044 s [User: 22.454 s, System: 0.938 s]
Range (min … max): 2.813 s … 2.964 s 10 runs
Summary
'8Threads' ran
1.21 ± 0.02 times faster than '4Threads'
1.57 ± 0.04 times faster than '2Threads'
2.25 ± 0.05 times faster than 'Current'
after 8 threads, there were no real performance benefits since the
overhead to load the module seems to be the biggest factor.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
instead of concatenating the eslint module into our app.js, ship
a 'pve-eslint' module that exports the built eslint module
to do this, we have to leave the module type on 'umd' instead of
changing to 'var' so that nodejs can properly import it.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Mainly to enable the rest/spread operator (...variable).
Other new features include asynchronous iteration,
Promise.prototype.finally and additions to RegExp (look behind, named
capture groups, s flag)
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
We use both, 'no-extra-parens' and 'no-mixed-operators' rules and
those can conflict. Thus follow eslints recommendation[0] and allow
parenthesis in nestedBinaryExpressions to avoid the linter
complaining either way. Do this also fo enforceForArrowConditionals
as there I saw the issue already in practice for me.
[0]: https://eslint.org/docs/rules/no-mixed-operators#rule-details
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
In generally we follow it but we want also to allow statements like:
let foo = bar
? 'baz'
: 'foz'
;
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Moving the message and the info if something is auto-fixable to a
single line, saving ~ 2/3rd of output lines.
The auto-fixable got replaced with a (*) marker, it's not ideal but
IMO OK; explain what it means in the summaries "X issues marked with
(*) could be auto-fixed"
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
we use this many times, and it really should not be confusing,
also it is much shorter than: 'Boolean(foo)',
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
This is a bit strange behaviour, especially if there's nothing to
lint and one gets just a spewed out nodejs backtracke.. It's not hard
to just to `eslint *.js` or the like..
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
who the heck makes the following syntax the default:
> foo.
> bar().
> baz();
So let's enforce the right thing™ and enforce the dot sticking to the
property, not the object, i.e.:
> foo
> .bar().
> .baz();
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
