Size Limit, a tool to prevent JavaScript libraries bloat, released

A tool that allows you to know the exact amount of kilobytes the JS library increases the user bundle has been launched
06 July 2017   1485
Continuous integration

In software engineering, continuous integration (CI) is the practice of merging all developer working copies to a shared mainline several times a day

Evil Martians Lead Developer Andrey Sitnik presents a tool that allows users to know exactly for how many kilobytes their JS library increases the user bundle. According to description, users now "can add Size Limit to their continuous integration service (such as Travis CI) and set the limit" and "if they accidentally add a massive dependency, Size Limit will throw an error".


JavaScript is a lightweight interpreted or JIT-compiled programming language with first-class functions

Size Limit in progress  Size Limit in progress

What is even more interesting about Size Limit, it can tell you not only the library size, but also why your library has this size, while showing real cost of all your internal dependencies.

What Size Limit actually does is that "it creates empty webpack project in memory. Then it adds your library as dependency to this project and calculate real cost of your libraries including all dependencies and webpack’s polyfills for process, etc".

As the creator of the tool Andrey Sitnik told us, Size Limit has emerged from Logux. The working process was conducted on weekends and overall it took 2 days to create Size Limit.

There're several browser components in Logux. I got really tired of the fact that many developers of libraries do not think about the price of dependencies at all and connect a lot of large unnecessary files. That's why I decided to take the issue of the final library size very seriously.

Andrey Sitnik
Evil Martians Lead Developer

As Andrey explains, any optimization necessarily begins with profiling. Thus, premature optimization is an "absolute evil" and you should always optimize only looking at metrics.

Unfortunately, there is no such opportunity as just to take a file and have a look at its size: this is an npm project consisting of many files and dependencies. Besides, the size of the library should be observed only after UglifyJS and gzip in order to be as close to "combat conditions" as possible. So that he put webpack.config.js in the project and wrote a couple of scripts that would pack the library into webpack and show the size.

Eventually, it was discovered that all these scripts for webpack and especially its configuration are larger than the library itself. A lot of unnecessary files appeared in the library folder, so the developer of Size Limit created an independent project to connect them to his libraries with the single line.

Thus, with the help of Size Limit Andrey Sitnik managed to improve the size of Logux Client greatly, which was an increase of 2-3 times.

Webpack Bundle Analyzer showed two problems:

  • The first one was node-uuid using. The size of the file was larger than the Logux Client itself. At the same time there was a need for a real UUID, a random sequence would be enough. So the developer had to switch to an analog of smaller size.
  • The second problem was that the library for DevTools color output was connected. The library itself wasn't large at all, but its author used the process variable incorrectly. As a result, the webpack inserted a polyfile for the process, which was larger than the library. The report concerning the error was sent to the PR author.

As far as CI services preferences are concerned, Andrey Sitnik claims that Travis CI is an industrial standard for open source. He carries out additional testing on AppVeyor for PostCSS to make sure that tests pass on Windows. The author of Size Limit also uses a full paid version of Travis CI in work. In Evil Martians, the company in which he works, everyone has experience with Travis CI and it is convenient to use it for closed projects as well.

Matrix & Riot Hosts Shut Down Due to Hack

Matrix team says that the hacking was done through a vulnerability in an un-upgraded Jenkins continuous integration system
12 April 2019   347

The developers of the platform for decentralized messaging Matrix have announced an emergency shutdown of the servers and (the main client of the Matrix) in connection with the hacking of the project infrastructure. The first shutdown took place last night, after which the servers were restored, and the applications were reassembled from the reference source. But a few minutes ago the servers were compromised a second time.

The attackers placed on the main page of the project detailed information about the server configuration and the data on whether they have a database with hashes of almost five and a half million Matrix users. As evidence, hash password of project leader is in open access. The modified site code is placed in the repository of attackers on GitHub (not in the official matrix repository). Details about the second hack are not yet available.

After the first hacking, the Matrix team published a report stating that the hacking was done through a vulnerability in an un-upgraded Jenkins continuous integration system. After gaining access to the server with Jenkins, the attackers intercepted the SSH keys and were able to access other infrastructure servers. It was stated that the source code and packages were not affected by the attack. The attack also did not affect servers. But the attackers gained access to the main DBMS, which also contains unencrypted messages, access tokens and password hashes.

All users were adviced to change passwords. But in the process of changing passwords in the main Riot client, users are faced with the loss of files with backup copies of keys for restore encrypted correspondence and the inability to access message history.