@nextcloud/eslint-config

This is a package containing the unified global eslint config used by all nextcloud apps and libraries. It contains the necessary dependencies and peerDependencies so that other apps cannot update if this config does not support it. Please always use dependabot to update your apps, OR pay attention to the peer dependencies error messages!

The rules within this configuration are based on, and enforce, the Nextcloud coding style. Additionally, we follow the common code styles and best practices used in the Vue ecosystem as we strongly focussed on Vue based UI code.

Tip

For backend code there is also a similar configuration for PHP code available enforcing our PHP codestyle, see Nextcloud cs-fixer.

Installation

npm install --save-dev @nextcloud/eslint-config

Usage

Note

Since version 9 this package depends on ESLint 9, which uses the new flat config system.

This package provides some predefined configurations you can choose from. For the recommended setup add a file eslint.config.js in the root directory of your app repository with the following content:

import { recommended } from '@nextcloud/eslint-config'

export default [
	...recommended,
]

Available configurations

Instead of the recommended configuration this package also provides some alternatives, depending on your app setup you can also choose:

• recommended
  • General rules including code style
  • Support for Typescript
  • Support for Vue 3
  • Support Vue files with Typescript syntax (the script within .vue files will be handled as Typescript).
• recommendedJavascript
  • Same as recommended but Vue files (the script part) will be handled as Javascript.
• recommendedVue2
  • Same as recommended but Vue files are considered in Vue 2 syntax.
• recommendedVue2Javascript
  • Same as recommended but Vue files are considered in Vue 2 syntax and the script part will be handled as Javascript instead of Typescript.

Configurations for Nextcloud libraries

For libraries some of the presets make no sense, like checking Nextcloud deprecated API. But on the otherhand some rules should be enforced, like documenting all properties. So for libraries use following configurations:

• recommendedLibrary
• recommendedVue2Library

Bundled plugins

This configuration also provides some bundled plugins with new rules, those options are already included in the recommended configurations.

It is possible to override the recommended configurations:

// eslint.config.js
import { recommended } from '@nextcloud/eslint-config'
export default [
	...recommended,
	{
		files: ['**/*.js'],
		rules: {
			// Make deprecations error instead of warning level
			'@nextcloud/no-deprecations': ['error'],
		}
	}
]

You can even use the plugins without using the Nextcloud ESLint config:

// eslint.config.js
import { nextcloudPlugin } from '@nextcloud/eslint-config'
export default [
	{
		files: ['**/*.js'],
		plugins: {
			'@nextcloud': nextcloudPlugin,
		},
		rules: {
			'@nextcloud/no-removed-apis': ['error', { targetVersion: '29.0.0' }],
		},
	}
]

package-json plugin

Rules:

• sort-package-json
  • Ensures the package.json is sorted in consistent order
  • Included as error level in recommended configurations

@nextcloud plugin

Rules:

• no-deprecations
  • Report usage of deprecated Nextcloud API
  • Included as warn level in recommended configuration
  • Available options

    {
      /**
       * Limit deprecated API to specified Nextcloud version
       * @example '29.0.0'
       * @default ''
       */
      targetVersion?: string
      /**
       * Try to find appinfo.xml to detect targetVersion
       * @default true
       */
      parseAppInfo?: boolean
    }

• no-removed-apis
  • Report usage of removed Nextcloud API
  • Included as error level in recommended configuration
  • Available options

    {
      /**
       * Limit removed API to specified Nextcloud version
       * @example '29.0.0'
       * @default ''
       */
      targetVersion?: string
      /**
       * Try to find appinfo.xml to detect targetVersion
       * @default true
       */
      parseAppInfo?: boolean
    }

@nextcloud-l10n

import { l10nPlugin  } from '@nextcloud/eslint-config'

Rules:

• enforce-ellipsis
  • Enforce consistent usageof ellipsis instead of tripple dots
  • Included as error level in recommended configuration
• non-breaking-space
  • Enforce non-breaking spaces before ellipsis
  • Included as error level in recommended configuration

Adding custom overrides

Sometimes additional rules need to be added for individual projects, and while we do not recommend to override Nextcloud rules for code style (it should be consistent across all Nextcloud projects!), it is possible to add such custom rules.

For example to enforce chains to be on separate lines:

- const a = foo().then((a) => a.b).catch((e) => e.c)
+ const a = foo()
+ 	.then((a) => a.b)
+ 	.catch((e) => e.c)

Adjust your eslint.config.js like this:

import { recommended } from '@nextcloud/eslint-config'

export default [
	...recommended,
	{
		rules: {
			'@stylistic/newline-per-chained-call': ['error'],
		}
	},
]

Update policy

We follow semantic versioning.

💥 Breaking changes

For breaking changes, we consider those changes that break linting in a technical term, so linting itself is broken with the update. This means, for example, require a new config format (ESLint legacy vs flat configuration). But it does not mean new errors or warnings while linting.

✨ Minor changes

For minor changes we consider adding new rules or adding or removing plugins. This means after updating a minor version, there can be new warnings or errors when linting the same code base.

🐛 Patch changes

For this configuration we consider following changes fixes:

• Adjusting rules to follow our official code style.
• Adjusting rules if the current behavior is considered a bug.
• Removing rules

Development

New rules

Adding new rules that enforce our code style can always be added. Rules that are not directly covered by our code style should be discussed before.

If those rules are code style related, the matching section of the Nextcloud developer documentation has to be updated to keep both in sync.

Rule severity

Either you care about a rule or you do not. As such we only enforce rules that we consider either important for code quality or to have consistent code style. For this reason all rules should be set to error severity, as all rules are considered must-follow.

Of course, in some edge cases rules do not apply, in such cases the users can still opt-in to disable that rule for a line or file.

To not break projects during updates new rules with non critical impact (code style related rules) should be introduced with warn severity and moved to severity error only with a new major release or after a sane timeframe for migration.

Release new version

• Pull the latest changes from main or stableX
• Checkout a new branch with the tag name (e.g v9.0.1): git checkout -b v<version>
• Run npm version patch --no-git-tag-version (npm version minor --no-git-tag-version if minor). This will return a new version name, make sure it matches what you expect
• Generate the changelog content from the release page. Create a draft release, select the previous tag, click generate then paste the content to the CHANGELOG.md file
  1. adjust the links to the merged pull requests and authors so that the changelog also works outside of GitHub by running npm run prerelease:format-changelog. This will apply this regex: by @([^ ]+) in ((https://github.com/)nextcloud-libraries/eslint-config/pull/(\d+)) Which this as the replacement: [\#$4]($2) \([$1]($3$1)\)
  2. use the the version as tag AND title (e.g v4.0.1)
  3. add the changelog content as description (https://github.com/nextcloud-libraries/eslint-config/releases)
• Commit, push and create PR
• Get your PR reviewed and merged
• Create a milestone with the follow-up version at https://github.com/nextcloud-libraries/eslint-config/milestones
• Move all open tickets and PRs to the follow-up
• Close the milestone of the version you release
• Publish the previously drafted release on GitHub