Update current tooling versions

[aryanjasala]

Rough items:

• The lint-js job is currently failing because ESLint has updated to v9, which defaults to "Flat Config" (eslint.config.js). It no longer supports .eslintignore and is looking for the new config format. We’ll need to migrate our .eslintrc to the new format or use the compatibility transform.
• Update theme.json version
• Update NPM dependencies

[Swanand01]

Based on initial research, here are some recommendations for the tooling package:

Build Tool: @wordpress/scripts

wp-scripts is the foundation. It ships with @wordpress/eslint-plugin as a dependency.

ESLint

Config format: flat config only (eslint.config.mjs). The legacy .eslintrc format is deprecated.

Ruleset: recommended from @wordpress/eslint-plugin. Covers this.

TypeScript support is opt-in: activates only if typescript is installed.

Recommended overrides in the shared config:

• jsdoc/require-jsdoc: off: JSDoc enforcement might not be needed not client projects
• no-console: warn instead of error: needed during development; error` creates unnecessary friction

In eslint.config.mjs:

import wordpress from '@wordpress/eslint-plugin';

export default [
  ...wordpress.configs.recommended,
  {
    rules: {
      // project-level overrides
    },
  },
];

Prettier

prettier and @wordpress/prettier-config need to be installed explicitly. These are not bundled with wp-scripts.

• prettier: installing this is enough to activate Prettier formatting enforcement. The ESLint plugin detects it and runs Prettier as part of linting automatically.
• @wordpress/prettier-config: sets WP formatting conventions (tabs, 80-char print width). Without this, Prettier falls back to its own defaults (2 spaces) which conflicts with WP standards. Reference it in package.json: "prettier": "@wordpress/prettier-config"

In package.json:

"prettier": "@wordpress/prettier-config"

Stylelint

Use @wordpress/stylelint-config

{
    "extends": "@wordpress/stylelint-config"
}

[aryanjasala]

jsdoc/require-jsdoc: off: JSDoc enforcement might not be needed not client projects

@Swanand01 In my opinion, adhering to good coding standards necessitates the inclusion of documentation within the code itself. This ensures that even when multiple developers are collaborating on a project, they can easily comprehend the code’s context.

[aryanjasala]

@Swanand01 Can you also create a list of tools/standards which we are dropping from the current implementation of Plugin/Theme, and the reasons for them as well.

What I would suggest is, create a list of current tools, and then mark them by (No-action, Drop, New-Addition), you can create a GSheet maybe, it would be easier to collaborate over there

[Swanand01]

@aryanjasala Thanks! The old eslint config had some rules that are definitely of use. Here's the updated sheet: https://docs.google.com/spreadsheets/d/1CScQBg5EwnFnyRlRNTJM30sCrzrAO_Bs1i3U7MpxgcM/edit?usp=sharing