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 github.com 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".
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.
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.