GSoC 2019: Starting Off the Dev Server Refactor
I’ve been selected to work with webpack for Google Summer of Code 2019. It is both a thrill and an honor to be able to contribute to such a useful development tool as a GSoC student! I’m looking forward to making my mark on webpack, and learning a lot along the way.
About Me
I go by Loonride online, but you can also call me Kir. I’m a first year undergraduate student at the University of Chicago, majoring in Computer Science. I’m originally from near Chicago.
I got my start in JavaScript through browser game development many years ago. Most of my JavaScript and NodeJS experience has come from creating games and other hobby projects. My latest project is an ambitious 2D multiplayer browser game called Cavegame.io! I often share my projects on GitHub, but beyond that, I had minimal Open Source experience before jumping into GSoC.
My webpack Story
I learned about webpack around 1 year ago. I was looking for a way to more easily bundle my game assets and source code together. My first experience with it was painful. I was dissatisfied with it, because it took too long to compile. If only someone had told me about the webpack Dev Server! I stopped using webpack for a while, but I later came across a project on GitHub that was using it effectively, so I gave it a second chance.
Now, I could never live without webpack! I use it in all of my projects, and it makes my workflow easy and efficient. I learned how to use webpack effectively, but how it actually worked still remained a mystery to me.
When I looked through the list of GSoC organizations and saw webpack, I immediately knew that I wanted to submit a proposal. It excited me that a GSoC project could directly benefit my own personal endeavors, like my game development projects, while also helping thousands, if not millions, of other developers with their own projects. Aside from the impact, it interested me that I could use this opportunity to demystify this tool that I relied so heavily on, while also diving into Open Source.
Why I Chose the Dev Server
The webpack Dev Server was listed as a GSoC proposal idea, and it seemed like an obvious choice for me from the start. I have experience with WebSockets and WebSocket servers in Node, so I knew I had the skills to work on moving the Dev Server away from SockJS, and towards a native WebSockets client implementation by default.
I also like the Dev Server as an option because I personally find it to be an essential webpack tool. It has made development extremely easy for me, as it allows for quick recompiling and iteration.
Contributing
I started contributing by looking through Dev Server issues and seeking out what seemed easiest. My first contribution was an HTTP/2 option, and it taught me how to add new options, how to add tests, and how to go through the PR process. After taking that first step, I felt a lot more confident that I could learn how the Dev Server and the rest of webpack work.
Next, I decided to tackle a bigger issue, which related to the insertion of entries into the user’s webpack compilation. The issue was that there was inconsistent behavior between the CLI and the API, because the API was not inserting those scripts on its own. While working on the problem, I came across this issue:
It’s the oldest issue on the Dev Server that is still open, and it brings up some lasting problems with uniformity. Reflecting on this issue gave me lots of ideas for my proposal, and made me realize that there really is lots of work to be done when it comes to improving the Dev Server. The major issue of uniformity lies in how the CLI interacts with and alters Dev Server options before passing them on to the API. I will take more steps to solve this during my project.
While working on my proposal, I also took a careful look at the SockJS client and server implementation in the Dev Server. The other key part of my project will be encapsulating these implementations so that we can create new implementations, like native WebSockets and ws, or even let the user provide their own implementation.
What’s Next
To start off the bulk of my project, I will be refactoring the SockJS implementation in the Dev Server, while maintaining backwards compatibility. The goal is that I can then easily swap in WebSockets and a WebSocket server without breaking anything, so that it can eventually become the new default implementation in place of SockJS. The reasoning behind this is that, while SockJS works at the moment, it is outdated, poorly maintained, and slower than native WebSockets. A proper refactor will allow the user to provide their own implementation, as well as use the client-server implementation to relay their own messages. I will also ensure that using SockJS still remains possible, since it works on some older browsers that don’t support WebSockets.
When it comes to CLI/API uniformity, I would like to work to move most of the options handling that the CLI does into the API, since the CLI eventually just calls the API. Another potential method for minimizing differences is to move the Dev Server CLI fully into webpack-cli. From a development standpoint, this would emphasize that we need to keep all the functionality inside of the Dev Server API, then do minimal work in the CLI itself. I will start making this transfer to webpack-cli during my project.
The way that the Dev Server was designed creates some challenges for the uniformity that I want to improve upon. Namely, the CLI creates the webpack Compiler, so it can make changes to its options before passing it on to the API. Consequently, the API can’t easily make changes to the webpack Compiler options, since the Compiler has already been created. With any remaining time I have, I hope that I can add features that make it easier to alter the Compiler configuration after it has been created.
Final Remarks
My project is ambitious and spans multiple aspects of the webpack Dev Server, but I’m confident that I can make improvements in all of those aspects during my refactor. Above all, I want to have a positive impact (without breaking anything, of course), while also learning and gaining a bunch through Open Source contributions!
