Add rule(s) to sort keys in nuxt.config.ts to keep everything in order

[stefanobartoletti]

Describe the feature

As a possible new feature, I think that it could be useful to have a rule to keep nuxt.config.ts clean and tidy by sorting its keys with specific criteria.

The inspiration for this is the jsonc/sort-keys rule that is often used to keep package.json ordered according to a specific pattern.

Especially when a project grows, nuxt.config.ts can become quite large and contain many configuration items.

A possible example could be

export default defineNuxtConfig({
  // place "modules" section first, and keep all entries alphabetically sorted.
  modules: [
    '@nuxt/image',
    '@nuxtjs/seo',
    'nuxt-icon',
    // and so on
  ],
  
  // other builtin config items
  css: ['~/assets/css/fontface.css'],
  components: { 
    // ...
  }
  
  // modules options, maybe alphabetically
  
  image: {
    //
  }
  
  // and so on

})

This is just an example of possible sorting criteria, but there can be even better I think.

I don't know if it is a good idea to have some preset rules for this, or if it is just something best left to the user.

Additional information

• Would you be willing to help implement this feature?
• Could this feature be implemented as a module?

Final checks

• Read the contribution guide.
• Check existing discussions and issues.

[antfu]

I'd love to have that! It does not seem very hard to implement, but it more like how we can agree with a specific order.

Here are the top-level keys we have extracted from our schema file.

[
  "components",
  "imports",
  "pages",
  "telemetry",
  "devtools",
  "vue",
  "app",
  "spaLoadingTemplate",
  "plugins",
  "css",
  "unhead",
  "builder",
  "sourcemap",
  "logLevel",
  "build",
  "optimization",
  "extends",
  "compatibilityDate",
  "theme",
  "rootDir",
  "workspaceDir",
  "srcDir",
  "serverDir",
  "buildDir",
  "appId",
  "buildId",
  "modulesDir",
  "analyzeDir",
  "dev",
  "test",
  "debug",
  "ssr",
  "modules",
  "dir",
  "extensions",
  "alias",
  "ignoreOptions",
  "ignorePrefix",
  "ignore",
  "watch",
  "watchers",
  "hooks",
  "runtimeConfig",
  "appConfig",
  "$schema",
  "devServer",
  "future",
  "features",
  "experimental",
  "generate",
  "_majorVersion",
  "_legacyGenerate",
  "_start",
  "_build",
  "_generate",
  "_prepare",
  "_cli",
  "_requiredModules",
  "_nuxtConfigFile",
  "_nuxtConfigFiles",
  "appDir",
  "_installedModules",
  "_modules",
  "nitro",
  "routeRules",
  "serverHandlers",
  "devServerHandlers",
  "postcss",
  "router",
  "typescript",
  "vite",
  "webpack"
]

[antfu]

I roughly ordered them from my understanding: https://github.com/nuxt/eslint/blob/feat/rule-config-orders/packages/eslint-plugin/src/rules/nuxt-config-keys-order/keys.ts

/cc @danielroe @atinux Do you like this direction (later we could enable it in @nuxt/eslint? If so, do you have any suggestions for the order?

[stefanobartoletti]

Thanks @antfu that looks awesome!

I like the general idea that seems to emerge, so those that probably are the most used keys are close to the top (in example, it is very handy to have modules visible without having to scroll the file).

Also, for sub-keys, in example the list of installed modules, a simple alphabetical sorting could be enforced too, to guarantee an order even there (helpful for diff's)

I would add that in addition to the official keys, there will be the modules config entries, and maybe they can be put at the end of the official keys in a simple alphabetical order too.

[dsvgl]

Please then make this an opt-in. Or at least opt-out. 🙏🏻

[manniL]

@dsvgl As it is an ESLint rule, you can always configure/override it 😋

What'd be your preference on the rule itself?

[dsvgl]

@manniL yes, overriding is possible. I don’t want this feature at all so, I‘d rather have a module option (like currently done for eg. tooling and stylistic) to opt-out instead of manually overriding this in the eslint.config file.
Also, not sure if having it „on“ by default is the best default. Other module options are initially false. Having it being false too (opt-in) would be more in line with the other options.