The event followed an “unconference” format, which was a first for me. There wasn’t a fixed schedule or pre-decided talks — anyone could propose a session, and people would just gather if they were interested. Honestly, I loved it. It made the whole experience a lot more spontaneous and interactive. Instead of listening to slides, we were all sharing experiences, asking questions, and learning from each other in real time.

There were people from all corners of the open-source world — from developer tooling and programming languages to CI/CD, academia, Hardware, Robotics, and AI. It was fascinating to see how differently (and yet, how similarly) communities deal with challenges like funding, governance, and onboarding new contributors.

A big topic that came up throughout the summit was the rise of AI-generated GSoC proposals, something a lot of organizations, including webpack, have noticed recently. The Google Open Source team made it clear that it’s up to each org to decide how to handle it, but it was interesting to hear what others are doing.

The general direction seems to be: stop overvaluing lengthy proposals and instead look at real contributions. Most orgs are now focusing more on:

• Small, meaningful pull requests or “good first issues”
• Short interviews or video calls to discuss those contributions
• Ensuring applicants actually understand the work they’ve done

This makes total sense to me. GSoC has never been about outsourcing features, it’s about learning, mentorship, and growth. We want contributors who care about the community and the craft, not just completing a project for the summer.

For webpack, programs like GSoC have always been about building people, not just code. Personally, GSoC holds a very special place in my journey. I was a GSoC student myself back in 2020, and you can find my old blog about that experience here.

That program marked the beginning of my open-source journey, and it shaped how I view collaboration and mentorship today. Fast forward to 2025, I’ve now transitioned from being a student to a maintainer, GSoC mentor, and a member of the webpack Technical Steering Committee. It’s been a rewarding full-circle moment, guiding new contributors along the same path that once shaped my own career.

There was also a valuable discussion about diversity and inclusion in open source, something every community should prioritize more. We discussed how to create safer and more welcoming spaces for people from all backgrounds. I strongly believe that diverse communities make better software. Different perspectives lead to better decisions, and better decisions lead to better projects. It’s not easy work, but it’s absolutely worth doing.

The summit was just two days long, but it was packed with great conversations and connections. The unconference format made it feel less like a formal event and more like a community get-together, which, to me, is exactly what open source is about. Here are few photos from the event:

Big thanks to Google’s Open Source Program team for organizing and sponsoring this event, and for giving us the space to come together, learn from each other, and share what we’ve built. It was truly an honor to represent webpack at the GSoC Mentor Summit 2025, and I’m heading back home with a lot of ideas, inspiration, and gratitude for this amazing community.

Google Summer of Code Mentor Summit 2025 was originally published in webpack on Medium, where people are continuing the conversation by highlighting and responding to this story.

This year was the 20th anniversary of GSoC and I had the opportunity to represent webpack in the Mentor Summit in Sunnyvale, CA.

The event hosted ~220 mentors and org admins from a wide variety of amazing open source organisations like PSF, Chromium, Zulip etc. who all came together to provide insights to attendees as hosted sessions. Interacting with such diverse set of organisations really broadened my horizon I had about Open Source.

The GSoC mentor summit followed the “unconference” structure wherein the mentors come together and decide the agenda as opposed to having all the events planned out. This provided the flexibility to propose session almost about anything and then having a group discussion to talk about a problem and how to fix it or something the org did this year differently and the impact it had.

I have always been a believer of Open Source but after the event it was clearer how indispensable it is to all the piece of technology we have today. The people do an amazing job in making all the tools, libraries and applications and maintaining them. Open Source sustainability is hard and I really appreciate the effort that Google is putting in to help sustain it with the program.

We really appreciate all the contributors contributed to webpack this summer and also the who expressed interest in contributing to webpack. The mentor team at webpack has been nothing short of awesome to collaborate with. I would also like to thanks Even Stensberg for coordinating the program.

Here are some moments from the conference —

Lastly, I would like to thank all the program admins and volunteers who made the event such a success. Their energy and the passion they’ve shown throughout the event has been inspiring.

If you are interested in participating as a student for webpack during Google of Code or you want to contribute to webpack, please do reach out to us, we would love to get you started! ♥

Thank you!

Anshu

GSoC Mentor Summit 2024 @Sunnyvale was originally published in webpack on Medium, where people are continuing the conversation by highlighting and responding to this story.

I’m super excited because I’ve been selected to work with webpack for Google Summer of Code 2020. It is both a thrill and an honor for me to be able to contribute to such a useful and wideemail you when the publication editor hasly used development tool as a GSoC student!

From knowing little about webpack before the organizations were announced, to being selected as one of the students, it has been a great ride. I can’t stress my gratitude towards the webpack community for being so helpful and welcoming to new contributors. I’m looking forward to making my mark on webpack, and learning a lot along the way.

< About Me />

My name is Nitin Kumar (I go by @snitin315 online), I am currently in the 2nd year of my Bachelor in Technology Degree from Maharaja Agrasen Institute of Technology (Affiliated to GGSIPU), Delhi in Electronics and Communications Engineering. I have been tinkering with code since my first year. I love working on Web Apps, as well as the related tools & technologies which make Web Apps possible and I have spent many of my nights up hacking on such projects.

< My Open Source Journey />

I started my open source contributions with FOSSASIA organization as a participant of the codeheat contest organized by FOSSASIA annually. I chose to work on eventyay project. This contest taught me a lot about Teamwork, Problem Solving, Ability to find and fix bugs, Review code of other teammates, etc. I learned how to provide efficient and high-quality code.

After seeing my contributions in the FOSSASIA organization, Mario Behling (Co-Founder of FOSSASIA) invited me personally to be a mentor in Google Code-In 2019–20.

Hence, I spent my winters mentoring pre-university students throughout the development of projects.

Finally, the result of the contest was announced and I was selected as a FINALIST WINNER.

I was looking forward to apply for GSOC with FOSSASIA but unfortunately FOSSASIA wasn’t selected as a mentor organization this year.

webpack- from ZERO to GSoC

webpack has always been the backbone of everything one does in front-end development. I always feared to dive deeper into the webpack or understand how it works internally. I got extremely thrilled and intrigued the day organizations list came out and I discovered webpack on the list. I made webpack my target goal and didn’t even bother to look for the rest of the organizations.

< Contributing />

After discovering webpack on the list and webpack-cli as a project in the idealist, I instantly started contributing to webpack CLI. The CLI has introduced with a goal to improve webpack user experience by providing flexibility. Apart from compiling builds and setting up webpack for an existing/new project, it comes handy for migrating webpack configuration for version upgrades and also to add, update, or remove properties from existing configurations.

When I cloned the project and checked the source code I wasn’t able to understand anything at all. Then I realized I need to dive deeper into webpack and luckily I found some workshop videos by Sean T. Larkin ( Founder of the webpack Core Team ) which helped me a lot to understand webpack core concepts and their internal working behind the scenes as well.

Side by side I was continually creating pull requests for improving documentation, fixing minor typos, and correcting grammatical errors. It took me 14 days to get my first major PR merged ( which was the addition of the — no-mode flag to CLI ). After this PR I felt very confident and it increased my pace & quality of contributions. I was able to get around 30 PRs merged prior to GSOC ( which seemed impossible when I looked at the source code for the first time ).

Finally, it was the day when GSoC students and projects were about to be announced. I remember refreshing my inbox every 2 minutes and yes I received an email saying “ GSoC 2020: Congratulations, your proposal with webpack has been accepted! ”.

< Work To Do in Summer />

During this summer, I’m going to kick-off this summer with the most crucial thing on webpack-cli roadmap like —

> Now webpack 5 provides API for CLI arguments so we will be taking arguments from the core itself.

> allowing multiple types of same arguments e.g — stats (means stats: true) and — stats verbose (means stats: verbose).

> Allow multiple same arguments, i.e. webpack --entry=./src/one.js --entry=./src/two.js

> I will add some negated boolean arguments like — no-hot and — no-stats

> Refactor to TypeScript .

> Writing unit tests and integration tests and many more general improvements.

Last but not least

I believe that I will finish the job at the end of happiness. Let’s enjoy it!

GSOC 2020 with webpack was originally published in webpack on Medium, where people are continuing the conversation by highlighting and responding to this story.

This year, two of our Mentors have participated in the closing conference, Google Summer of Code Mentor Summit in Munich, Germany. During the conference, mentors from all organizations met and spoke about important topics that are relevant for every Open Source organization out there. As an organization, it is important to care about the community, ecosystem and how the organization is helping making the Open Source space better, which we do (!a lot!).

The summit hosted representatives from Git, Sugarlabs, FreeBSD, UN, MetaBrainz, governments and many other awesome organizations! These representatives provided insight in various of sessions together with other mentors on how we together could help sustainability, the ecosystem both in software and in the world of climate as well.

During these sessions, discussions about sustainability in projects, pull request review processes and building a healthy community was one of the core values, which was talked about in great depth and by people that care, which from a maintainers perspective, was amazing to be apart of.

Discussions of Operating Systems and burnout were also on the agenda. All these topics were really important, and from our perspective: Valuable to how we reason about Open Source governance, helping the world progress and thrive.

After attending this conference, it’s clear that the hardship of Open Source is everyones problem, not just the problems webpack are facing. The community as a whole does an immense job at making tools, libraries and source more available. Seeing so many passionate, smart and inspiring people communicate, collaborate and work together has been an eye-opener for us, and there is no doubt that the ecosystem is in the best hands, maintained by the most genuine people.

As mentors this year, we appreciate the work put into from students and other people that continues to make webpack better over time, day by day. This project is driven by the community, which is the way Open Source should be run. Thank you for this years students that made an incredible effort into their projects, making code cleaner and reporting better! Finally, thank you to all other contributors that continues to put in the effort to make the web better. A few people I want to thank, is Alexander Krasnoyarov, Eugene Hlushko and Emanuele Stoppa.

Thanks to all new contributors, welcome at any time to contribute to webpack, existing ones that aren’t mentioned, but still do tremendous efforts, thank you!!

Below is a few pictures we took during the conference.

Thanks to everyone involved, organizers and attendees, it was a great event and we thank everyone for having a safe and inclusive community that genuinely cares about the future of Open Source!

If you are interested in participating as a student for webpack during Google of Code or you want to contribute to webpack, please do reach out to us, we would love to get you started! ♥

Our mentors, maintainers and contributors are friendly, we do not bite. You can contact us through twitter at our individual handles.

Again, thank you for an eye-opening experience!

Even Stensberg & Steven Hargrove

Google Summer of Code Closing Conference was originally published in webpack on Medium, where people are continuing the conversation by highlighting and responding to this story.

This Google Summer of Code, I worked on a couple of key components in the webpack Dev Server: the client-server WebSocket communications, and the CLI. Most of my work was focused towards PRs for webpack-dev-server, with occasional, project-related work in webpack-cli and documentation work in webpack.js.org.

The Dev Server is a tool that allows users to develop and serve webpack apps with live reloading browser capabilities. I’ll be sharing what I have added and changed, how my efforts will impact this tool, and what lies ahead.

GitHub - webpack/webpack-dev-server: Serves a webpack app. Updates the browser on changes. Documentation https://webpack.js.org/configuration/dev-server/.

Brief Overview of Changes

The major goals of my GSoC with the Dev Server were completed. These goals were: adding ws and native WebSockets as a transport option to eventually replace SockJS, refactoring the CLI, and improving tests. Here is the status of these changes, and links to the relevant work:

• transportMode option, allowing users to specify ‘ws’ in place of ‘sockjs’ (merged and published, relevant PRs)
• CLI Refactor, minimalizing CLI/API inconsistency (some published, others merged and awaiting next major release, relevant PRs)
• wepack-cli serve refactor (merged and awaiting next major webpack-cli release, relevant PRs)
• Test improvements, including end-to-end tests and adding tests for untested features (merged and published, relevant PRs)
• Documentation of my features and changes (some published, other docs awaiting major Dev Server release, relevant PRs)

Luckily, virtually none of my work went to waste or went completely unused. There is still work to be done in refactoring the Dev Server, but everything directly related to my major project goals was completed.

Native WebSockets and ws

The first goal of my project was to make ws the new default server, a WebSocket server which can communicate with native browser WebSockets. These new defaults are meant to replace the current SockJS client/server implementation that the Dev Server uses. The motivation behind this change is that SockJS is poorly maintained and slower than ws with WebSockets.

ws

Backwards and Browser Compatibility

The difficulty of simply scrapping SockJS is that it offers support for older browser versions that do not support native WebSockets. My solution had to make it easy for users to swap back to SockJS, if they needed to support older browser versions for their projects.

My new system also had to do everything that the current SockJS server and client were already doing, preventing any breaking changes, aside from the browser compatibility issue. This meant that ws and native WebSockets would have to seamlessly swap with SockJS as the client/server implementation.

WebSocket-like Interface

In order to accomplish my goals, I first built a WebSocket-like interface for both the Dev Server client and server. To get the most out of this interface, I made it almost completely unassuming of what client/server library is being used.

The chosen server library simply needs to listen for new connections, produce a connection object for each new connection, and be able to send messages to this connection object, among a few other things. In essence, the server interface looks like this:

Then, using ws and slightly simplifying, the onConnection method implementation might look something like:

The client interface is similar, requiring simply that the client library can connect to a server and listen for messages.

The reason for this design is that ws, SockJS, and native WebSockets could then all be implemented via this unifying interface. This also has the added benefit that other WebSocket client/server libraries can be implemented in place of SockJS or ws.

devServer.transportMode option

Using this interface, I implemented two modes: ‘sockjs’ and ‘ws’. Then, I added a new transportMode option, with which users can, for example, do:

Using this mode makes use of the ws server and native browser WebSockets.

Custom, user-implemented Client/Server

Beyond the simple ‘sockjs’ and ‘ws’ modes, users can now implement their own transportMode using the interface mentioned above. Instead of specifying an already implemented mode as a string, you can provide:

These are absolute paths to files exporting classes that implement the interface mentioned above. As I said earlier, this is simply a customizable benefit that came from creating a versatile, unassuming, WebSocket-like interface.

But what can you actually do with this customizability? The main use case would be to implement a specific server/client library that you desire, rather than using the provided sockjs or ws options. The key is that the client and server must be compatible to communicate. Let’s say, for example, that you do not want to use ws as a Node WebSocket server, but instead want to use websocket, another Node WebSocket server implementation. You still want native browser WebSockets. First, you would use the server implementation interface and plug in the websocket library:

To make use of this custom server implementation, paired with the native browser WebSocket implementation that is provided, you would simply do:

With these tools now available, users will be more capable of customizing the Dev Server to their needs, and the Dev Server will become easier to maintain as standards and transport libraries change.

CLI Refactor

The next step of my Google Summer of Code was to start refactoring the Dev Server CLI. The motivations behind this refactor were:

1. There is inconsistency between the Dev Server API and CLI usage, making some options confusing to use
2. Moving the CLI into the serve package of webpack-cli will improve the user experience, as webpack-cli is focused on making it easier to create and modify webpack projects

Removing CLI config changes

Inconsistency between the Dev Server API and CLI stems from the fact that the CLI utilizes the API, but first makes some configuration changes to the user’s provided CLI options. My thought process was that, if these changes are made to make the user experience better, API users should receive the same changes, and therefore the same benefits and consistency.

Let’s look at a few lines of code directly from the Dev Server to demonstrate what I mean. These lines of code are only executed when the user is using the CLI:

options is the options object that the user has provided in their webpack config file, and firstWpOpt is the webpack options object that will be passed into the compiler, also from the user’s webpack config file. This makes the user experience better because it infers the user’s desired watchOptions from the webpack config they provided, meaning the user does not have to include these options twice for both the webpack compiler and the webpack Dev Server.

API users did not get this feature. This is one of many examples where the API did not make changes to the options consistent with the CLI.

My solution is simple to explain: I started moving all configuration changes from the CLI to the API. Ultimately, I planned to design the CLI such that it simply parsed the CLI arguments, then passed that parsed argument object directly into the API, with zero configuration changes. In a very boiled down example, the CLI should do the following:

Breaking Changes

Because I wanted to bring the CLI and API inconsistencies to a minimum, there were many minor breaking changes involved. The example earlier of inferring a Dev Server option from the webpack options, for instance, would be a minor breaking change for the API.

For this reason, all of my changes to the CLI will be coming in the next major Dev Server version. Ultimately, these breaking changes will have a positive impact.

webpack-cli serve

My work on this command in the serve package of webpack-cli is part of the next major version effort for webpack-cli. Previously, the webpack-cli serve command simply made use of the Dev Server CLI. My goal was to make this command instead use the Dev Server API directly.

Since webpack-cli is also undergoing a refactor for the next major version, my work here involved bootstrapping the serve command using the new webpack-cli infrastructure, and parsing the Dev Server arguments using command-line-args, rather than the previously used yargs.

From these CLI improvements, users get many benefits: more consistent and predictable usage between the CLI and the API, as well as a better user experience from webpack-cli.

Dev Server Tests

While working on my main feature and refactor efforts mentioned above, I also dedicated some time to improving test coverage and stability. My main work here involved:

1. Adding end-to-end tests and improving their stability
2. Adding tests for previously untested features that I dealt with

What’s next for the Dev Server

My goals for GSoC 2019 were accomplished. I implemented ws and native WebSockets via the transportMode option, and I refactored the Dev Server CLI. Some of these changes have been released, and some have yet to be released as of the writing of this post, as they will arrive in the next major versions of webpack-dev-server and webpack-cli. But there are still things to be done to improve the Dev Server, which I hope I can continue to be a part of!

Upcoming for the webpack-dev-server will be the version 4 release, as the final version 3 release has already been published. This will have to coincide with the next major version of webpack-cli, as webpack-cli serve changes will rely on major changes in webpack-dev-server. Other things to expect for the Dev Server in the future will include a refactor to organize the client directories more thoughtfully, and possibly TypeScript, to name a couple.

This Google Summer of Code has been a great experience for me, and I’m very thankful that I got to do my work for webpack! I plan to continue contributing to webpack and hopefully expanding beyond the Dev Server.

GSoC 2019 Dev Server Refactor: WebSockets, ws, and CLI was originally published in webpack on Medium, where people are continuing the conversation by highlighting and responding to this story.

Here we are at the end of the GSOC 2019, seems yesterday that I wrote the first article before beginning my work for webpack, check it out if you want to have an overview of my project (link).

Long story short, in those 3 months I’ve developed a plugin called ReporterPlugin that helps to customize webpack’s output. You can read more on the Github repo and you can find it on npm as test-webpack-reporter-plugin.

The purpose of this plugin is to offer a more informative and CI friendly way of outputting information, offering an improvement over what is available at the moment:

• making easier to understand what webpack is doing, for example, you should now know where your compilation broke in a more chronologically accurate and predictable format
• reducing the time required to customize the information displayed, making easy to override webpack’s output, to remove it completely or to define any custom behavior (e.g. dumping log to a file)

What I’ve not been able to do in 3 months, is finding a different name for this plugin since webpack-reporter-plugin is already taken

Fundamental Concepts

Those are some fundamental concepts to understand the purpose of this project and how to use it.

Hooks

You can think of hooks as event listeners, you can use myHook.tap(callback) to add a listener that will be executed when myHook.call(params) will be called.

Hooks are provided by a library called tapable and are used extensively in webpack’s code to implement the plugin system (e.g. compiler.hooks.done is called every time a compilation has finished).

This plugin uses hooks in 2 ways:

1. Listens to every webpack’s hook in order to be able to log whatever is happening during a compilation
2. Provides 4 new hooks (info, warn, error and stats) allowing to easily write a CustomReporter to handle all logs

CustomReporter(s)

A CustomReporter is the actual piece of code that you will write in case you want to override webpack’s output. A Reporter taps into the ReporterPlugin’s hooks (info, warn, error and stats) specifying how to print all those kind of logs. While it’s straightforward to think of a custom reporter as something that formats and prints logs, it also covers use cases where you are not interested in printing but instead, you may want to dump all the logs into a file or forward them to a web server. Wrapping it up, a CustomReporter is something that listens to 4 different kinds of logs (info, warn, error and stats) and handles them as needed.

Configurations

Since this plugin is meant to be used by anybody without requiring too much knowledge of webpack’s internals, it has good default settings so that it doesn’t need configurations to work, although, you can harness its power by tweaking the configurations. Through the configurations, you can decide which hooks you want your Reporter to report or to exclude and you can also pass one or more CustomReporters

Throttling

Sometimes some hooks are called many times during a webpack run, this plugin allows you to limit those “noisy” hooks. You can set a value to tell this plugin to emit a log for a specific hook only once every N times or every N milliseconds.

My work

After being selected for this GSOC I talked with my mentors and opened some discussion to gather feedback from the community, receiving great suggestions on the infrastructure design (webpack#9137) and the plugin configuration schema (webpack-reporter-plugin#2)

I started working on the bare bones of the project implementing the infrastructure that makes this plugin extensible with CustomReporters with the goal of providing a simple and friendly way of defining reporters. The result is that reporters are easy to write and look familiar to everyone that has seen the code of a webpack’s plugins.

After that, I refined the first implementation and made the plugin customizable through settings. After defining the schema, the other important task was to validate it to avoid errors. I used a library called schema-utils before implementing my own wrapper around a JSON validator called ajv to have more control over error messages.

When everything was in place I started writing documentation and tests. I decided to test if the plugin was able to validate and parse the configurations, listen and report the hooks according to the configurations and lastly I tested the correct behavior of the default reporter. This part has been really instructive and helped me discover and fix some problems.

While working on this project I looked at many webpack-contrib repositories and made mine as similar as possible to those in order to make it easier for people from the community to understand and possibly contribute to it. I’ve set up linting & commit linting to ensure consistency of code and commits and Travis CI and codecov to automate quality checks.

Conclusions

This is my second GSOC and it has been very different from my previous one for many reasons:

In 2015 I was really new to the Javascript world, I had no OSS experience, I was only writing vanilla JS, I had basic knowledge of Git and working on my project has been pretty challenging.

Now instead, I’m familiar with the Javascript ecosystem and I’ve contributed to webpack-cli for some months before GSOC and working on my project has been quite smooth.

What hasn’t changed is the amazingness of this experience, something that I would suggest to every student!

</Summer 2019 with webpack> was originally published in webpack on Medium, where people are continuing the conversation by highlighting and responding to this story.

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!

GSoC 2019: Starting Off the Dev Server Refactor was originally published in webpack on Medium, where people are continuing the conversation by highlighting and responding to this story.

Summer 2019 with webpack

My view this summer will be slightly different from the one in the image above, however, I’m super excited because I’ve been selected to work on improving webpack during this summer!

About me

My name is Devid, I’m mastering computer science at the University of Bologna (Italy). I’m a Javascript developer and I’m passionate about technological developments in general.

I made my first open source contribution in 2015 while I was working as a GSoC student for the MIT App Inventor, I still have a great memory of that summer and all the great people I got to know.

When I don’t code, I organize, attend and speak at technical events, I play video games and exercise at the gym.

You can find me on Twitter as @misterdev_ and on Github as @misterdev.

webpack: from zero to GSoC

I’ve used webpack many times in my projects since around 2016. I started learning webpack more in depth and wrote my first configuration last year, when I decided to apply for webpack for the GSoC 2018.

Devid from 2018: “I’ve already been a GSoC student and I worked 2 years in a local startup as a full-stack developer, this is gonna be easy, let’s pick the most difficult proposal…mmh multithreading in webpack? Yeah! I know nothing about webpack internals and multithreading in Javascript, I can definitely do this! Let me fix a typo in the documentation and send my application”

SPOILER: I wasn’t selected

After the summer, inspired by people I really admire for their work (like kentcdodds and sindresorhus), I decided to start contributing to an Open Source project despite not being selected. My top choices were webpack, Node, and Yarn, I chose to go on with webpack.

I spent the first month solving a problem just to find out it was the intended behavior 😅 but I learned a lot about how webpack works. Since then, I’ve tried and documented every single webpack hook (parser, compilation, and compiler), made an Open Collective prompt for webpack-cli, helped with the scaffolding system and the CI. I published my first package on npm and wrote my first medium article.

Fun fact: I’m not able to write “webcam” anymore, my muscle memory writes “webpcam” or directly “webpack”

My work for the summer

This summer I’m going to work on the “Output Reporter”, the purpose of this project is simple: to provide a way to override webpack’s output. Currently is hard to customize the default output, therefore it would be great to have a way to make the creation of custom reporters easier. In webpack, the compilation stats is standardized, outputting large pieces of information and it’s hard to get something out from it all.

What I’m thinking, is that there are currently two ways of overriding webpack’s output: you can use a plugin (e.g. ProgressPlugin, webpackbar, friendly-errors-webpack-plugin) or set the “stats” option to configure which bundle information you want to display (picture below). Of course, you could also write your own plugin but it requires a knowledge of how webpack works internally.

The “stats” option can only be used for a final output after compilation and you may not find a plugin covering your use case, another solution is needed…

The Output Reporter project is meant to improve the current usefulness of webpack’s output, we want to make it more informative about the current state of the compilation, allowing to comprehend the information given from the compiler, where webpack spends most of the time or where it fails to compile. This is very similar to the ProgressPlugin with the intention to be more CI friendly (avoiding buffered output) and allowing the possibility to throttle noisy hooks to limit the frequency of the output.

My initial proof of concept was to have an EventEmitter inside webpack emitting a set of events like “warning”, “error”, “log”, and “stats” so that anyone could write a custom reporter that listens to these events, formats, and prints the output.

After being selected, I’ve received many great suggestions from @hulkish and @sokra, the initial idea has slightly changed, but it’s way better now!

I’m going to build off the original proposal, creating a webpack plugin that can be configured with one or more custom reporters. Instead of an EventEmitter, I’ll use the tapable interface to emit a set of events, which is a library created by webpack to implement the plugin system.

Summing it up, I’m going to create a new plugin system for reporters, so custom reporters are going to be similar to a classic webpack plugin:

class CustomReporter {
  apply(reporter) {
    // Adds a listener for a specific log: "info"
    reporter.hooks.info.tap("CustomReporter", data => {
      // Formats and prints the output
      console.log("I'M THE REPORTER: ", data);
   });
  }
}

Here’s the discussion on this, feel free to give your feedback on the implementation.

Final Remarks

GSoC 2015 has been a key point in my path as a developer, it improved my English a lot and gave me solid grounds in web development. Furthermore, seeing my commitment being rewarded and completing what I had been selected for, is a great satisfaction, that kind of confidence boost is good for everyone. I’m sure this year will be another great experience…

Devid from 2019: “I know a little about video editing, nothing about photography, and my English accent is arguable… let’s make a series of videos covering the summer of a GSoC student for webpack” :)

I use this space at the end to give a very big thanks to Even Stensberg, I’m sure I wouldn’t be here without his precious feedback :) 🔥🔥

Summer 2019 with Webpack was originally published in webpack on Medium, where people are continuing the conversation by highlighting and responding to this story.

Every now and then we hear people make jokes about configuration being hard. It’s true, and webpack hasn’t been the most trivial tool to use when getting into web development.

That’s why we are changing the interface and webpack. When doing this, we are making the CLI of webpack better to look at, simpler to use and easier for users to understand.

With this goal in mind, we are confident that users will spend less time setting up the tool itself, to spending more time doing the fun part, actually developing the application. We do not want users to give up on web development once encountering webpack, rather we want to encourage people to have less configuration when starting and then making more advanced builds as they develop a traditional web application.

One of the best search results from google had the word “beginners guide” in it, which indicates that we have made a bad job at making the CLI of webpack easy to use.

We are sorry…

Ives Van Hoorne, the creator of CodeSandBox made this great illustration of how development feels like. It makes sense, because we want the user to use less time figuring out how things work to have more time developing an application. As webpack itself is a tool that is flexible, we do not need to make a web application perfect at once, but rather over time and by setting good default values for users.

Webpack-CLI will try to set the best defaults for you, meaning that we will optimize your build as much as we can, making it easier for you to have a fast application with no configuration. We are also making it easier for users to start different kinds of configurations such as React, SAAS or similar. This will allow you as a user to run webpack-cli without having to specify anything. The good stuff.

Removing flags

In the newest version of webpack-cli, we will remove a lot of specific flags that we think is too advanced to be in the CLI. We encourage users to write specific logic for their builds through a webpack configuration rather than writing a one-liner with 1337 characters.

The result of this is that the new CLI will be cleaner, provide more clarity to new users, the output will (finally) be more prettier, less rubbish in the output of a compilation and we will set good defaults.

Good defaults in this case would be that you will have performance optimizations out of the box, loading styles, files are easier based on your current project structure as well as development and production flags will be improved.

Adding Flags

We will add a few new flags to make debugging and developing in watch mode easier, webpack-ui is going to be released later in v4, a merge flag to merge two configurations together will be added and finally, node flags are going to be supported.

Webpack-UI will be released along with a command/flag named webpack interactive. These two flags are targeted for helping new users understand webpack in a graphical way, to debug webpack interactively and provider a more convenient platform to run webpack from rather than from the Command Line Interface.

The changes are coming in the upcoming webpack-cli version, version 4.0.0 and it will be released in alpha by the end of December. We will release the CLI in a slow matter, to ensure that people reliant on the old CLI flag, will have backwards compatibility. A more detailed post along with proper documentation of how to migrate your application will be published soon as we release the alpha version for you to test and experiment with.

We are changing the interface of webpack-cli — here’s why was originally published in webpack on Medium, where people are continuing the conversation by highlighting and responding to this story.

Rebuilding Webpack CLI

After more than 52 merged PRs and 75 commits in webpack’s CLI, we are at the end of a journey.

Webpack CLI encapsulates all code related to CLI handling. It captures options and sends them to webpack compiler. You can also find functionality for initializing a project and migrating between versions.

Abstract Syntax Tree Optimisations 🌲

Abstract Syntax Tree or AST is a hierarchical tree-like representation of the code. It helps us understand and read relationships between different elements of the code. An AST transformation is an action of modifying this tree (i.e. changing an existing AST to a new AST).

Let’s take a look at how an AST looks for a simple webpack config like this:

Each and every part of our code is formed of AST nodes which can be of various types like Object Expression, Member Expression, Literals, Variable Declaration, etc.

Once we have an AST of the full webpack config, we can manipulate or transform it for implementing useful features like migrating webpack configuration for version upgrades or also to add, update or remove properties from existing configurations.

For doing all the manipulations and transforms in AST, we use a library called jscodeshift developed by Facebook. This is the same library which is used by React folks for developing react-codemod. jscodeshift provides a nice interface for playing around with AST paths, node builders and traversals.

We have a lots of utility methods written around the jscodeshift API which we use as wrappers in our commands. Earlier, we started with using a non-recursive approach towards AST transformations for generation of new AST nodes in the init command. As new features and cases came in and the nodes scaled, we realised that this was not an efficient way of handling transforms as each case needed to be handled differently depending on the kind of node we want to generate and attach to the tree. It was hard to maintain deep nesting for nodes as well. This resulted in a lot of code and utils which were hard to scale and maintain.

To fix this, we took a recursive approach for adding and updating AST nodes which handles all types of nodes and works with deep nesting implicitly. Hundreds of lines of code reduced to 50 lines recursive function. It was a huge maintenance improvement for team and potential to implement new commands like add/update. Kudos to Even Stensberg!

This enabled implementing add or update command which is one of the newest command we shipped a while ago that enables users to add new webpack properties from the CLI directly. We merged the logic used for creating and updating of AST nodes to support this new command.

Remove command is another newly released commands which is used for removing existing properties from webpack configuration files. Our end goal for this command was to remove a specific property from the config file without disturbing the rest of the contents and validating it.

One of the initial thoughts we had were to somehow reuse the recursive function used for adding so we thought of re-generating a new AST without the node selected to remove. This was costly due to regeneration of the entire tree. In fact, we didn’t need any recursive approach for removal of AST nodes as we only have to remove a targeted node leaving rest of the tree unaffected. For instance, in loaders/rules, we don’t need to drill recursively inside each option for each rule. We show a list of rules based on their names (picking up their loader property) and then a prompt to remove only a specific targeted rule object from the rules array. For objects like devServer, we show a list of keys like port, contentBase, filename, etc. It made more sense to follow the non-recursive approach for this use-case.

Some of the PRs that went into this work: #456, #461, #500.

TypeScript migration

Migration from JavaScript to TypeScript was one of the most discussed open issue for more than 6 months.

Introducing TypeScript gave a good stability to the codebase and help us trim down documentation at some places. It also unlocked code completion, prediction and reduced the likelihood of runtime errors and help form a good internal code documentation. It’s a big win for all.

We started with a gradual migration with help of allowJs flag so that we can migrate the codebase in chunks.

TypeScript with Monorepos 📦

Recently, we migrated to a monorepo strategy using lerna which allows us to ship small mono packages instead of a big monolith package. To follow the principles of mono packages, we integrated TypeScript build system not just at root level but also at every package level since each package should be independent of each other. We also setup linting using TSLint following our previous ESLint style.

One of the challenges we found while working with TypeScript is a little initial cost for setting up all the custom interfaces for all the methods and objects we’re using in the code. It’s definitely worthwhile of an exercise. To add typing support for npm modules, we straightaway went with the DefinitelyTyped type definitions. Also, some of the modules like chalk come pre-bundled with types. For npm modules that neither come with types nor have DefinitelyTyped support, we created custom module interfaces again. Integrating custom module type definition is easy with help of Triple-Slash Directive that uses a reference path but in most cases, the TS compiler is smart enough to pick all the declaration files. Using custom module types made us choose the signature and shape of each method and object exposed by the module. We needed to be cautious enough not to mismatch the underlying JS behaviour used by the libraries.

We also plan to add the missing modules to DefinitelyTyped by contributing the declaration files we created for the npm modules missing types. We haven’t done that already since we only wrote types for the method we were consuming in our codebase.

TypeScript compiled code is not always backwards compatible ♻️

The core entrypoint of the CLI is a bin folder which contains logic for handling of all the flags and command options. We decided to stick with JavaScript for this part of the codebase in order to keep friction low for new contributors who might not be familiar with TypeScript. We’re still evaluating how new contributions are impacting after this big change in language, style of coding and might shift to TypeScript for all files once we’re confident that everyone is comfortable with it.

In order to stitch TypeScript compiled code with this existing JavaScript code, we had to make some minor with the way we are importing this compiled code. One particular thing we would recommend is avoiding default exports in TypeScript if you want to import your compiled JavaScript code into other parts of the codebase using JavaScript.

To understand one of the pain points of working with TypeScript and JavaScript code together, let’s take a look at how the TypeScript compiles code to JavaScript:

Notice how the compiler created a named export with variable default instead of module.exports. Now, in order to import this compiled module in JavaScript, we have to use a require syntax like this:

Some of the PRs that went into this work: #511, #550.

Migrate Configs - Webpack 3 to 4 🔢

webpack 4 (Legato) was released around 5 months back and is one of the biggest releases webpack has done.

🎼webpack 4: released today!!✨

Most new use-cases worked out of the box with the new #0CJS support and sensible defaults. A lot of changes were made in the existing API to unlock higher optimisation levels. One of the biggest change in the public API is the transition from CommonChunkPlugin to SplitChunksPlugin.

Originally, chunks (and modules imported inside them) were connected by a parent-child relationship in the internal webpack graph. The CommonsChunkPlugin was used to avoid duplicated dependencies across them, but further optimizations were not possible

Since webpack v4, the CommonsChunkPlugin was removed in favour of optimization.splitChunks.

We want to make this transition smooth for our existing users using the nifty migrate feature we already had for migrating from version 1 to 2. We also show a nice little diff on what exact changes the CLI is going to do in the config during migration process.

We started with version 3 to 4 migration during mid-April and are happy to announce that we’re getting the final pieces to get in place for a smoother transition. We will release this big feature soon after some internal testing.

Some of the PRs that went into this work: #558

Miscellaneous improvements

• Added autocomplete support for configuration properties for add command. #502

• Upgraded major version for all dependencies. #290
• Greenkeeper support for automating dependency management.
• Support for custom paths to webpack configuration files for add command. #501

Lessons Learned 💂

Working on big open-source projects and tough and exciting. The best part is having your work directly impacting hundreds of thousands of developers who use webpack.

There are a lot of learnings that comes along with experience and familiarity with the core team and community. Collaboration and team effort are key for the success to any large scale project.

Community matters a lot. We should never forget the end goal of what we’re trying to solve and always listen to what the community needs and the concerns they share.

Adapting to existing code and following design patterns help maintain consistency throughout the application. Always write composable, maintainable and loosely coupled code which makes scaling easy.

GSoC and webpack is probably the biggest breakthrough of my career. Can’t thank enough to Google and webpack for giving me this amazing platform. This opportunity definitely has a very huge impact on me. It has allowed me to grow from an open-source contributor to an open-source maintainer.

Big shoutout to Even Stensberg, Sean T. Larkin and Tobias Koppers for helping me throughout the programme and being such a good mentors and teachers. ❤️

Next on the CLI roadmap 🚀

Some of the things that we have next on the roadmap are refactoring the entrypoint folder to decrease some bloat and making it easier to maintain, improvements in the documentation along with the release of new commands and lots of user-experience revamp like an introduction of an interactive mode or dashboard.

It's a wrap: Google 🌞 of Code was originally published in webpack on Medium, where people are continuing the conversation by highlighting and responding to this story.