ESLint configuration for ServiceNow

August 3, 2025

Do you want to increase code quality in your ServiceNow instance, standardize coding style across all your development teams, ensure better readability of your code? Yes, then you can configure ESLint with additional rules to achieve it.

This blog introduces my recommended ESLint configuration for the ServiceNow platform taking into consideration few ServiceNow specifics. I have added several new rules on top of what ServiceNow brings baseline. Many of these rules are about coding style and readability. These are inspired by the most widely used style guides for Javascript like Airbnb Javascript Style Guide or Prettier. I try to focus on the most useful rules while trying to keep the configuration simple.

I believe that every ServiceNow customer should have a well defined ServiceNow Coding Style Guide to ensure that the code is written in a consistent and smooth style. As Robert C. Martin says in his book Clean Code: “The last thing we want to do is add more complexity to the source code by writing it in a jumble of different individual styles.”. By the way, I heavily recommend to read this book!

What is ESLint

ESLint is a tool that statically analyzes your code to quickly find problems with the goal of making code more consistent and avoiding bugs. It is used by ServiceNow within its Script Editor. As of New York release, we can configure which ESLint rules are applied in our instance by simply updating related system properties.

Example of a warning shown by ESLint within the Script Editor.

These warnings and errors are in real-time shown to developers and they can fix it. Be aware that ServiceNow does NOT enforce these warnings and errors to be really fixed. The developers can still save the record. This is good when customizing baseline scripts (as your rules might not be met by all the baseline code and you do not want to fix formatting of baseline code). On the other side, it means we require a good peer review process if we do not want to let these errors and warnings being pushed to production.

How is ESLint configured baseline?

Baseline configuration of ESLint is stored in 2 system properties:

• glide.ui.syntax_editor.linter.eslint_config - for scripts that are still in EcmaScript 5
• glide.ui.syntax_editor.linter.eslint_config.ecmascript2021 - for scripts that have EcmaScript 12 enabled

They contain roughly 45-50 rules that ServiceNow decided are a good standard. They focus on the most common mistakes that might lead to bugs. Examples might be that you cannot assign new value to a constant, or have an empty block statement.

You can check all the rules within your ServiceNow instance or PDI. The purpose of this blog is not to explains all these rules.

Why should you add more?

Don’t you want to detect more coding issues early on and automatically? If yes, then you want to extent your usage of ESLint. If there are a good rules to be added, why not to do it when ServiceNow gave us the opportunity?

My recommendation is to add not only bug detection rules but also style & readability related rules. As stated above, each team should agree on the standardized code formatting & style. This standard should then be ideally automatically validated which the ESLint can fulfill. In ServiceNow environments, it is best to define a standard for the whole ServiceNow platform so that all your internal developers, or external partners follow the same rules.

Imagine this scenario when 2 different developers use completely different conding style and each of them writes a method into a shared Script Include. Sometimes, these developers could argue which one is more readable. However, our goal is that no single developer owns the code just because of the way and style he used to write it. Anybody should be able to update or extend it afterwards. Therefore, you want to have a unified style guide used by all developers!

Let me share few examples of what I recommend you to standardize in your ServiceNow instances.

Naming convention

All developers should follow similar naming convention for variables, methods and classes in their code. The most widely adopted style guides for Javascript follow the "camel case" convention and so should we probably.

Brace style

Braces and bracket standards might differ a lot among programming languages. For maintainability and readability reasons it is good if the whole ServiceNow instance follows the same standard. There are many ESLint rules validating which brace style to use for arrays, keywords, functions, objects etc. Do your best to standardize it.

Spacing

Spaces make code more readable. Standardization of spacing is good as it helps to read the code. Robert C. Martin claims in his Clean Code book that the ratio of time spent reading versus writing is well over 10 to 1. As he says "We are constantly reading old code as part of the effort to write new code."

Where to start?

Do you want to expand your usage of ESLint but do not know where and how to start? Are you lost in hundreds of ESLint rules that you could potentially use?

I have published first version of my public ESLint configuration for ServiceNow. Feel free to use it. Read the readme, check the added rules, agree with your teams and developers if those are acceptable in your environments. Then install it in your non-production environment to test it.

• GitHub Repository: DominikSimunek/sn-eslint-configuration

• ServiceNow Share Project: ESLint configuration for ServiceNow

There is a brief explanation of all additional rules that I have added. More details can always be found on ESLint site with nice examples: https://eslint.org/docs/latest/

Benefits of this ESLint configuration for ServiceNow

• It is ServiceNow-specific and avoids an enormous amount of "false positives" by skipping some rules that do not fit the ServiceNow environment.
• It supports ServiceNow exceptions for camel case naming convention that are common in ServiceNow (e.g., incidentGR.caller_id).
• It is aligned with the most widely used style guides like Airbnb and Prettier, making it easy for JavaScript developers to adopt.
• It is not overcomplicated, and it does not require complex maintenance (e.g., listing names of script include classes).

A great resource for you about ESLint is from Maik Skoddow. Check it out here: Reduce smelling code and detect JavaScript issues with ESLint

Do you want my support to implement a Coding Style Guide for your ServiceNow platform? Reach out to me. I can help with aligning coding standards with your teams, define the standards and implement them using ESLint and other tools like Instance Scan into your ServiceNow platform. Write me a message: dominik@dominiksimunek.com.

Do you want to contribute and help build a good, while simple ESLint configuration for ServiceNow? Reach out to me on GitHub or via email. I am open to improvement suggestions, as my first version is still far from perfect.