Understanding the product vision of ESLint is a good starting point for our architectural analysis. The vision of a product has an impact on design decisions. We cover the vision in six sections. First, the intended achievements of ESLint (section 1) and a description of the end-user mental model (section 2). Other key points of ESLint’s vision are the key capabilities and properties of the system (section 3), the stakeholders (section 4) and the current and future context (section 5). We end the product vision with a detailed roadmap, containing the future focus of ESLint, in section 6.
Goal of ESLint
These ideas can be found on the website of ESLint, which contains detailed information about the project1. The website states the primary reason why ESLint was created:
“The primary reason ESLint was created was to allow developers to create their own linting rules.” - JS Foundation and other contributors, source
- Find problems: using static analysis.
- Fix automatically: solve the found problems automatically.
- Customize: write your own customized rules, that can work alongside the default rules of ESLint.
End-User Mental Model
The end-user mental model for the developer is straightforward. The first aspect is that the developers want to install ESLint with a single command, after which they can immediately start using the tool with sane defaults. Secondly, when the need arises they want to be able to have their own linting rules. ESLint needs to support these custom rules of developers. The last aspect is that customizing the rules should be easy. Rules should be configurable with a simple config file and a collection of battle-tested rules should be available.
Capabilities and Properties
In order to accelerate developement and keep the project on track, it is important to keep an overview of the capabilities and properties.
ESLint is very straight forward in what it wants to achieve, but does it well. We can identify two main features that make up the ESLint project. With these two capabilities, ESLint is able to achieve its goal of helping developers with their projects.
- Find problems in projects: The ability to identify problems in a projects allows developers to create higher quality code and identify bad practices quicker.
- Fix issues automatically: ESLint can automatically fix issues based on the problems found. This increases the productivity of developers drastically. Developers will spend much less time fixing problems since ESLint will fix a lot of them automatically.
In this part, we will focus more on the properties of ESLint outside of analyzing and fixing source code. This is more focussed on how developers are able to incorporate ESLint into their workflow and what properties of ESLint allow developers to interact with ESLint easily.
- Integration with text editors: ESLint has integration with many text editors which makes ESLint easily accessible.
- Continuous integration: ESLint supports the use continuous integration to allow projects to maintain a certain code quality by setting a limit to the amount of errors/warnings for example.
- Customizable rules: Since ESLint is open-source, any developer can add its own rules. In the long term this will make ESLint much better, since new rules will only increase code quality even further.
In Software Systems Architecture2, Rozanski and Woods, stakeholders are defined as “groups of people with their own interests, requirements and needs they need from the system.” Using public sources, ranging from GitHub issues to websites, we performed an analysis of these stakeholders. As a result of the project being open source and non-profit, some stakeholders are not as relevant. Identifying the stakeholders is fundamental to understand the role of architecture in the development of ESLint.
In the following table the major stakeholder types, their identified entities, and context is given.
|Type||Persons or Groups||Description|
|Assessors||Technical steering committee* & maintainers||There is no clear assessor group, due to the open-source and low-risk nature of the project. Legal wise, the maintainers make sure contributors agree with the license agreement.|
|Communicators||Technical steering committee*||The technical committee communicates the architecture and contribution direction to aid developers in contributing and communicate with (potential) sponsors to gain funding and continue development.|
|Developers||Technical steering committee*,
|Includes all the people who contribute to the repository: more specifically the ESLint team who are the largest contributors, but also the external small one-off contributors. Improving the system also makes their developing experience better.|
|Maintainers||ESLint Team||The team ensures that pull requests made by contributors adhere to all standards (quality, testing, documentation) and decides whether a feature should be merged in or not.|
|Suppliers||NPM, GitHub||Being commercial companies, other than providing a service their interest also lies in attracting large software projects.|
|Support Staff||ESLint Team, ESLint Community||While there is no dedicated support staff, the main support is given by the maintainers on GitHub issues and the community in Gitter and Google Groups.|
|System Administrators||Users||Users themselves are system administrators, they run the ESLint system on their projects once it is deployed.|
|Testers||Developers||We have not identified a separate testing group from developers, new features such as rules instead require developers themselves to supply a test suite, as can be seen here for example.|
|Users||Developers and companies (e.g. Facebook, Netflix, Airbnb) which employees use ESLint||ESLint is used and installed by millions of developers every week. These users want a system that implements linting rules and is as stable as possible. The interest of the users is that their code quality will increase.|
A special type of stakeholder we identified are the sponsors, namely the ESLint Collective, consisting of large companies such as Facebook, Airbnb, and Shopify (in addition to individual backers). The purpose of the money mainly is to pay ESLint team members for development. Sponsors, however, do not get any extra influence in the development decisions of the project. Other than some small advertisements on the GitHub page, their interest solely lies in the continued development of the project, as the tool is valuable for their companies.
Another perspective we can use to analyze stakeholders is a power-interest grid. In the following figure, we lay out the previously identified stakeholders in that grid.
Current and Future Context
ESLint does not have a clear roadmap, but it creates regular releases. In each release, it is stated which new features have been implemented and which bugs have been fixed.
Aside from that ESLint seems to work with issues on their GitHub repository. The new rules that have to be implemented are listed in a document under different categories.3 The categories are TypeScript-specific, Functionality, Maintainability, Style, Testing, Miscellaneous, Security and Browser. In this list, it is clear which rules have to be implemented first, but there is no deadline for any.