chore: migrate to neostandard #2920 by johns70 · Pull Request #3201 · elastic/elasticsearch-js

johns70 · 2026-02-28T04:28:45Z

Hello! This is one of the few contributions I have made as a Junior. I did problem #2920 of moving the project from ts-standard to neostandard to support ESLint 9.

I set up the new eslint.config.mjs file and made sure to ignore the src/api/ folder as the guide says. I also fixed some warnings in the tests (like the descriptions of Symbol() and some any types) so that the linter would have 0 errors.

I reviewed everything with npm run test:unit and all 613 tests passed. I hope everything is correct!
Here is a screenshot of the tests passing locally:

prodsecmachine · 2026-02-28T04:29:00Z

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

JoshMock

Thanks for this contribution, @johns70! I left a few comments and suggestions.

I'll also note that you've dropped the comments disabling no-misused-new, no-extraneous-class and no-unused-vars from many of the code-generated files, but in some of those files the no-unused-vars disable is still present. Because those code files are 100% generated from the Elasticsearch spec, it will be easier to be consistent with what disable rules are kept at the top of each file.

JoshMock · 2026-03-02T18:09:24Z

eslint.config.mjs

+})
+
+export default [
+  //  Cargamos la configuración de neostandard


Since this repo targets English as its primary language, please ensure any comments are in English as well.

JoshMock · 2026-03-02T18:13:09Z

eslint.config.mjs

+  // Archivos a IGNORAR (Esto limpia la carpeta src/api)
+  {
+    ignores: [
+      'src/api/**',


While ignoring src/api/ seems helpful, we do want neostandard or eslint to auto-fix simple linting issues when these files are regenerated from the specification; the code generator does its best to output files in a consistent format but some rules around whitespace, line breaks, etc. are fixed by the linter before generated code is committed.

voxpelli

Some comments from my phone on my way to work 🙂

Thanks for the effort!

voxpelli · 2026-03-03T06:51:18Z

eslint.config.mjs

+  {
+    plugins: {
+      // Esto extrae el plugin de la base para que las reglas de abajo funcionen
+      '@typescript-eslint': baseConfig.find(c => c.plugins?.['@typescript-eslint'])?.plugins['@typescript-eslint']


We export the plugins for convenience, use that instead: https://github.com/neostandard/neostandard#usage-of-exported-plugin

voxpelli · 2026-03-03T06:53:09Z

eslint.config.mjs

+
+  // Archivos a IGNORAR (Esto limpia la carpeta src/api)
+  {
+    ignores: [


You can specify this as an ignores option to Neostandard: https://github.com/neostandard/neostandard?tab=readme-ov-file#configuration-options

voxpelli · 2026-03-03T06:54:39Z

package.json

    "@types/split2": "4.2.3",
    "@types/stoppable": "1.1.3",
+    "@typescript-eslint/eslint-plugin": "^8.56.1",
+    "@typescript-eslint/parser": "^8.56.1",


Do not add these directly, you must use the ones included in neostandard due to how ESLint handles deduping in configs

voxpelli · 2026-03-03T06:54:58Z

package.json

    "license-checker": "25.0.1",
    "minimist": "1.2.8",
    "ms": "2.1.3",
+    "neostandard": "^0.12.2",


You can upgrade to version 0.13.0 now 🥳

voxpelli · 2026-03-03T06:56:20Z

eslint.config.mjs

+  ts: true
+})
+
+export default [


Consider using defineConfig here: neostandard/neostandard#308

voxpelli · 2026-03-03T06:56:48Z

eslint.config.mjs

+  {
+    files: ['**/*.ts', '**/*.cts', '**/*.mts', '**/*.tsx'],
+    rules: {
+      'import-x/export': 'off'


No longer needed in Neostandard 0.13

eslint.config.mjs

voxpelli · 2026-03-03T06:58:23Z

eslint.config.mjs

+      // Esto extrae el plugin de la base para que las reglas de abajo funcionen
+      '@typescript-eslint': baseConfig.find(c => c.plugins?.['@typescript-eslint'])?.plugins['@typescript-eslint']
+    },
+    rules: {


I would recommend adding a comment on each rule change describing why it's necessary and/or better. This helps both project owners and us Neostandard maintainers.

voxpelli · 2026-03-03T06:58:50Z

package.json

    "test:integration": "npm run test:integration-build && env tap run --jobs=1 --reporter=junit --reporter-file=report-junit.xml generated-tests/",
-    "lint": "ts-standard src",
-    "lint:fix": "ts-standard --fix src",
+    "lint": "eslint .",


Suggested change

"lint": "eslint .",

"lint": "eslint",

This is enough nowadays

johns70 · 2026-03-04T01:18:43Z

Hello, I hope you are well, thank you for the corrections and the advice, my apologies for the inconvenience, I will make the change to the code right now

johns70 · 2026-03-07T03:33:54Z

A quick question: since neostandard 0.13 no longer provides the import/export rule, ESLint now throws Definition for rule 'import/export' was not found for the files generated in src/api.

Can I remove the /* eslint-disable import/export */ comments from the generated files, or re-add the plugin in the configuration? @voxpelli

voxpelli · 2026-03-09T00:19:55Z

@johns70 Remove the disable comments 👍

johns70 · 2026-03-13T02:34:16Z

Hi @JoshMock and @voxpelli ,

I hope you’re doing well. First of all, I want to apologize for how long it has taken me to make progress on this task; I haven’t had much time, and I try to use the minutes I have to move forward with my responsibilities. This task is very important to me.

The purpose of this message is to share some difficulties I’ve encountered with the linter regarding the auto-generated code in the lib and esm folders.

I’ve noticed that every time I run npm run test or npm run build, the files in lib and esm are regenerated automatically (I assume this is due to rimraf or another build mechanism, especially when running tests).

Because of this, when I try to use npx eslint . --fix, many style errors reappear—particularly indentation, semi, camelcase, and no-void. The --fix option cannot preserve changes in files that are regenerated.

So far, the only viable solutions I’ve found are:

Run npx eslint . --fix within the test script so that the auto-generated code is formatted automatically before running tests.

Completely ignore these folders in the ignore, although I’m somewhat hesitant because this could hide unexpected errors or break project consistency.

I’m not sure if I’m missing something in the Neostandard documentation that allows the linter to be permissive enough in certain cases with auto-generated code syntax. So far, I haven’t found another solution that is consistent and reliable.

My main question: is --fix intended to apply only to src files, or should it also work on generated code? And if it is expected to work on generated files, is there a recommended way to integrate it without having to ignore entire folders or run eslint --fix inside the tests?

Thank you for your time and guidance.

Best regards,

JoshMock · 2026-03-20T16:21:07Z

Completely ignore these folders in the ignore

This is the correct approach. We only need linting to cover code in src, test and scripts.

johns70 · 2026-03-25T02:28:13Z

@voxpelli, @JoshMock. Hello guys, I hope you are very well. I just uploaded the changes you asked me for. If there is any detail or problem, do not hesitate to tell me so I can correct it.

chore: migrate to neostandard elastic#2920

e7cf11b

johns70 requested a review from JoshMock as a code owner February 28, 2026 04:28

JoshMock requested changes Mar 2, 2026

View reviewed changes

voxpelli reviewed Mar 3, 2026

View reviewed changes

fix: adjust eslint config to handle generated code, tests and scripts

989d890

Merge branch 'main' into issue-elastic#2920

1d8ce10

Conversation

johns70 commented Feb 28, 2026

Uh oh!

prodsecmachine commented Feb 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ Snyk checks have passed. No issues have been found so far.

Uh oh!

JoshMock left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

voxpelli left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

johns70 commented Mar 4, 2026

Uh oh!

johns70 commented Mar 7, 2026

Uh oh!

voxpelli commented Mar 9, 2026

Uh oh!

johns70 commented Mar 13, 2026

Uh oh!

JoshMock commented Mar 20, 2026

Uh oh!

johns70 commented Mar 25, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

prodsecmachine commented Feb 28, 2026 •

edited

Loading