CI: use template's `eslint` job to validate YML and JS, add new `UI eslint` job for UI's TypeScript

+1 — yes please! 🙏

Anjali Mehta → made their first commit to this issue’s fork.

This will need a custom job to run `tsc check` against the ui folder too

fYI we will need to override the eslint job from the template and run `cd ui && npm run lint`

We should change scripts in package.json to make that include stylelint and tsc check

One question on the MR.

@larowlan is right in #9 that we need to add an extra step, but that can be achieved by doing:

eslint:
  before_script:
    - whateverweneedhere

That way, we'd reuse the template's eslint job 🤞

This blocks 📌 Update eslint prettier configuration Active . Hence escalating priority.

The benefit of using the GitLab CI template's eslint job is that we get nice reports inside the GitLab UI: https://git.drupalcode.org/project/experience_builder/-/pipelines/193684...

But … I realize that the template runs:

    - $CI_PROJECT_DIR/$_WEB_ROOT/core/node_modules/.bin/eslint --no-error-on-unmatched-pattern --ignore-pattern="*.es6.js" --resolve-plugins-relative-to=$CI_PROJECT_DIR/$_WEB_ROOT/core --ext=.js,.yml --format=junit --output-file=$CI_PROJECT_DIR/junit.xml $_ESLINT_EXTRA . || EXIT_CODE_FILE=$?

… as opposed to:

npm run lint

… which does this, per package.json:

"lint": "npm run lint:eslint && npm run type-check",

IOW: we've lost npm run type-check. That's bad. Perhaps a separate CI job?

And … shouldn't we use npm ci instead of npm i(nstall)? See https://stackoverflow.com/questions/52499617/what-is-the-difference-betw....

(Not using npm ci has caused enormous problems for me in the past 👻)

I pushed this forward as much as I could.

• The default eslint job should kept because it tightly integrates with the GitLab CI code quality functionality. It also validates YAML formatting.
• I agree that adding a separate CI job makes sense for ui/*, but then it should:
  1. ✅ it should run immediately since it does not use yarn anyway (done!)
  2. it should pass (when @larowlan added it, then CI pipeline was green, but that's only because the CI job didn't actually run…)
  3. ✅ both should run only when relevant
  4. We need a follow-up to impose coding standards on the Cypress tests

I’ve got 99% of the eslint MR green. The 1% remaining bits are solely in ui/, and require React Hooks knowledge I don’t have and
others could do 100x faster. It probably will take <5 mins for somebody more familiar with React. Let’s get this done today 🤞

https://git.drupalcode.org/project/experience_builder/-/pipelines/197062... is now listing actual failures thanks to junit 👍

Cannot be merged without @bnjmn's final sign-off 😅

Thanks to 📌 CODEOWNERS: expand + make more pragmatic for when people go on vacation Fixed being more liberal, we can move a bit faster. This has been ready for 2 days, so let's get this in — there's nothing controversial in here anyway, otherwise I'd definitely wait for @bnjmnm :)

We need a follow-up to impose coding standards on the Cypress tests

That already exists: 📌 Cypress test infrastructure clean-up + baseline E2E test Active .

Automatically closed - issue fixed for 2 weeks with no activity.

Follow-up: 📌 CI: improve UI-related CI jobs:`UI eslint` obscures TypeScript Compiler errors, `npm run build` runs too late Needs review .