Stabilizing webpack 3 (week 18–19)
You may noticed the title differs from previous logbook entries. This is intended. James Gillmore suggested to make the title a bit more attractive.
27 PRs were merged in the last 2 weeks and we released 3.5.0 plus multiple versions with bugfixes (up to 3.5.4).
Next to multiple new features (see changelog) it also included a refactoring for the (still experimental) Scope Hoisting plugin.
Updated Scope Hoisting
ModuleConcatenationPlugin only removed
imports to concatenated modules. Removed
imports are concatenated instead. Now it removes all
imports and concatenate references to “external” modules. This allows to evaluate all imported modules in the correct order (this was broken before). In addition to this, less
require calls are created, which should result in smaller bundles and faster execution.
I’m bit lazy in closing issues after they are answered (or not responding)… This resulted in many open issues that are no longer relevant. It would be easy to use the Github API to close all old issues, but this would also close issues that are still relevant.
So the plan was to comment on old issues to warn users about the automatic closing. This allow anybody to bump the issue to escape automatic closing. Without reaction the issue is closed after half a month.
I want to use the webpack-bot for this behavior to be a continuous process rather than a one-time script.
But the bot only reacts to github events. Inactive issue don’t emit events (elsewise they are no longer inactive). So I added a scheduling feature to the bot, which allows to schedule another bot investigation after a defined time.
At bot investigation we schedule another investigation after 24 hours for open issues. This results in regular investigations and allows to detect inactive issues after 178 days. Inactive issues are flagged with the
inactive label and users are warned with a comment. If a
inactive issue is inactive for 15 days it’s closed. Any activity on a
inactive issue removes the
The current funding status of webpack is 🙂. With Trivago donating $10k/mo, Segment sponsoring me for $8k/mo and ag-Grid donating $2.5k/mo we are in a good position. And we have additional $125k on progress base from Mozilla. Assuming nobody cancel their sponsorship we are well funded.
The money is primary used to pay contributors to any repository in the webpack or webpack-contrib organization. An automated tool guesses work done by contributors and assigns points per hour. A invoice can then be filed by the contributor to get paid for there work.
Notes: There is a lower cap so you need to contribute at least 12 hours to be considered. Every public activity on github counts as contribution: Answering questions, reviewing PRs, submitting PRs, filing issues, etc. (Trying to abuse the system may result in ban…) I may adjust the numbers a bit on individual base, i. e. rounding.
Currently an hour is worth about $25. With reaching the “well funded” status, we can increase the payment to $40/hour and lower the entry cap to 8 hours/month. I also want to add a bonus for long term contributors of another $10/month, totaling at $50/month. The bonus represents experience gained over time.
Notes: Some contributors were already paid by their employer for their contribution. These contributors are begged to not take additional money (no double pay).
The payment should be a compensation for work done. It should also make contributing more attractive for contributors.
More money → more contributors → more work done → better product.
For me this sounds like a great use of the funding, but I would love to hear more opinions how to use the money.
Plan for the next weeks
webpack 3 reached a good level of stability and features. I guess it’s a good point to stop adding features to webpack 3 and instead concentrating on the development of important breaking changes for webpack 4. There are already a bunch of open PRs for it. webpack 3 will only receive bug fixes or minor features.
webpack 3 was released on 2017–06–19. A major release every 3 months looks like a good plan.
One important feature for webpack 4 will be WebAssembly support. I also want to change the way how chunks are loaded (JSONP → Array push), to allow
async script tags. A few planned performance improvements are breaking changes too.
We will publish a beta version in this process… Stay tuned…
webpack is not backed by a big company, unlike many other big Open Source products. The development is funded by donations. Please consider donating if you depend on webpack… (Ask your boss!)
Special thanks to these sponsors: (Top 5)