feat: lint option for javascript template

[Mazuh]

resolves #363

Checklist

• run npm run unit
• tests and/or benchmarks are included
• documentation is changed or added
• commit message and code follows the Developer's Certification of Origin
  and the Code of conduct

for typescript, see: #512

[mcollina]

lgtm

[climba03003]

I would change the option to lint which can be extendable in future.

[Mazuh]

@climba03003, that's up to you folks to decide, but...

IMHO people that need something beyond the standard linter will probably do that with their own custom *rc files (.prettierc, .eslintrc), each one requiring extra dependencies (every eslint project has tons of different plugins listed on devdependencies), at least that's my experience, not to mention that eslint/prettier CLIs are already very customizable by themselves.

so, when I choose the boolean/binary approach, it was by design trying to prevent the cli of being redundant with eslint/prettier clis, prevent any kind of long discussion regarding code styles whenever I new one would be introduced via issue/PR, prevent the responsibility of maintaining any new linter set up-to-date forever and keep scope reasonably non-opinionated yet pragmatic about it -- tldr: I tried to avoid a lot of headache for maintainers.

anyway, that's a design choice, not really my decision to take, I'm available to make any changes, let me know what the rest of the reviews think and what should I do to get this merged.

[climba03003]

IMHO people that need something beyond the standard linter will probably do that with their own custom *rc files (.prettierc, .eslintrc), each one requiring extra dependencies (every eslint project has tons of different plugins listed on devdependencies), at least that's my experience, not to mention that eslint/prettier CLIs are already very customizable by themselves.

It is a string option which mean it can be extended like --lint=standard, --lint=eslint, etc.

[Eomm]

tldr: I tried to avoid a lot of headache for maintainers.

+1

I must say that it would be awesome to think of a "pluggable" cli (or a yeomen generator? 🤔 )

[mcollina]

lgtm

[climba03003]

I must say that it would be awesome to think of a "pluggable" cli (or a yeomen generator? 🤔 )

@Eomm I recommend to check this PR #491 which is interactive and provide more option than the current one.
And I need some help on the Github Actions problem.

[Mazuh]

@climba03003 @Eomm any feedback on this? should I assume that this PR should be closed (it looks like the issue is being worked on in another PR or something)?

[Eomm]

LGTM when ci green

[mcollina]

lgtm

[simoneb]

@Mazuh let's figure out the windows problem first

[Mazuh]

it was indeed just a testing issue, the rimraf.sync(...) that runs before each test behaves a little bit differently on windows, all others test cases were running fine but my little one stepped on a race condition and I was trying to generate the project in a busy directory.

now I have my ubuntu and my windows with npm t returning 0 (ok), so the same should happen with the pipeline, I'm going back to my macbook to confirm that everything is ok there too.

---

maybe it's worth to create an issue to refactor the test suite in another PR to use the async version of rimraf instead, but I'm not sure if this will also get in the middle of the big refactoring in progress on another PR.

[Mazuh]

Can one of you guys merge it, please? It seems all good now.

[mcollina]

@simoneb you good to land this?

[simoneb]

@mcollina yes LGTM