Build Tools - Suggested Improvements
Build Tool Research
WET uses Grunt to build its distribution files. Grunt performs tasks such as SASS parsing, minification, and building HTML pages from Handlebars templates. The current build tool, while powerful, is plagued by various ineffeciencies. What follows is the result of research for solving some of these issues.
With the current build tools, a full build of WET takes approximately 6 minutes to complete, with a variance of +/- 45 seconds. The tests run by Travis-CI add another 2 minutes to this process. This process must be run for any commit made to the WET repository. In this report we will detail how the build can be made more efficient as well as suggesting alternatives solutions to the build process.
The following is a list of the most time consuming tasks. These account for roughly 70% of the build time. Note that the durations listed are an approximation, and may vary by +/- 10 seconds.
- Building theme pages (90s)
- Minifying CSS (60s)
- Bootlint (60s)
- Building demo pages (25s)
- Building Documentation (20s)
With the removal of these tasks, as well as a few other unnecessary tasks, the build time can be reduced to around 30 seconds. This quick build would include all JS, CSS and assets. What follows are several areas where the building process could be improved.
1 - Partial State Caching
A solution that would increase development times significantly would be to implement a system of partial state caching. This means that a user would be able to do parts of the build as necessary, instead of running the entire build process. The advantage to this is that you can isolate your failures and fix them without needing to rebuild everything else that was already working. It would act as if you were able to pause the build at the point of error. If you have completed 75% of the build but then encounter an error you should be able to fix that error and rerun the build from the point of failure rather than the beginning. This improvement would be the most significant in terms of time saving. It would massively increase developer efficiency.
2 - Stop File Duplication
In the name of backwards compatibility, a change was made in 2015 that duplicates all JS, CSS and assets into the main directory. This adds 30mb to the folder size. Since these files are no longer needed for backwards compatibility, they should be deleted. There are even comments stating that backwards compatibility should be removed at some point in the future. In addition, there is a 10mb folder called unmin that contains unminified versions of many files. While access to unminified files is useful for development, they are not needed in a final distribution build and should be removed. The removal of all these unneeded files will halve the size of WET. Cutting the file size down by half will increase readability and ease of working with the file.
3 - Dropping support for IE 8
As of 2015-01-01, WET no longer supports Internet Explorer 8. Despite this, there is much old code still present for IE8 support. Removal of this legacy code would be a simple way to streamline the build.
4 - Documentation
The current Gruntfile is actually quite powerful. Much inefficiency arises simply from an unawareness of its capabilities. With proper documentation, any user could create a build in a fraction of the usual time. An increase in awareness and less confusion leads to an increase in community engagement as well as lowering the time spent on debugging.
5 - Optional Linting
The next idea is to make linting optional. In doing this it keeps the option for those in the community who want it but doesn’t make it required for every build. As stated previously in this report the bootlint takes around 1 minute to complete. Given that some developers do not feel that the linting is required, making it optional gives them the opportunity to develop quicker. That being said, to those who do find value in the linting process the option will still be available to them.
6 - Removing the Rakefile
Removing the rakefile has more to do with organization than it does with speed. The rakefile is a ruby file that checks to see if links are valid. When the grunt file was made there may not have been an NPM module that could complete this task but that is no longer the case. The rakefile could be replaced with an NPM module such as: broken-link-checker.