First off, thanks for taking the time to contribute! You're already faster than a webpack build on a cold start! 🚀
Fast is better than slow.
Measured is better than guessed.
Asynchronous is better than synchronous.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to npm install.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Brendan Eich.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's probably too slow.
If the implementation is easy to explain, it may be fast enough.
Namespaces are one honking great idea -- let's do more of those!
This project is all about measuring build times for webpack and vite projects. Because if you can't measure it, you can't improve it (and you can't complain about it with exact figures).
Remember, we're all about that F5 Experience here. Our goal is to make the development process smoother than a freshly transpiled TypeScript file. Here's what that means for contributors:
- Setup Should Be a Breeze: You should be able to clone the repo and get up and running faster than you can say "npm install".
- Fast Feedback Loop: We want our builds and tests to run faster than a promise resolves. If you find yourself waiting, something's wrong.
- Update the README.md with details of changes to the interface, this includes new environment variables, exposed ports, useful file locations and container parameters. Documentation is like a love letter to your future self.
- Increase the version numbers in any examples files and the README.md to the new version that this Pull Request would represent. We use SemVer, because we're not animals.
- You may merge the Pull Request in once you have the sign-off of two other developers, or if you don't have permission to do that, you may request the second reviewer to merge it for you. No lone wolves here!
Releases are driven by changesets, not by hand-edited version numbers. If your PR changes anything a consumer of a published package can observe, it needs a changeset:
pnpm changesetThat prompts for the affected packages, a major/minor/patch bump for each, and a summary, then writes a markdown file into .changeset/. Commit it with your PR. On merge to master the Changeset workflow rolls every pending changeset into a "Version Packages" PR that bumps versions and writes the CHANGELOGs; merging that is what publishes to npm.
So a release is two merges, not one. If your change is already on master but not on npm, the Version Packages PR is what you are waiting for.
Nothing user-visible? Skip it — CI-only, test-only and internal refactor PRs don't need a changeset.
Because changesets named it that. The filename is generated by human-id, which picks one word from each of three built-in lists — 200 adjectives, 300 nouns, 250 verbs — for about 15 million combinations. As the changesets source puts it:
Worth understanding that the ID merely needs to be a unique hash to avoid git conflicts — experimenting with human readable ids to make finding changesets easier
The name carries no meaning and never appears anywhere user-facing; only the file's contents reach the CHANGELOGs. Its whole job is to keep two people adding changesets on the same day from colliding on a filename. Renaming it to something descriptive is harmless if you prefer — changesets reads the directory, not the names.
In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.
Unless you're a console.log debugger. Then all bets are off. (Just kidding, we love all developers equally. Even those who think alert() is a valid form of error handling.)
We believe in test-driven development. In fact, we believe in it so much that we've created a tool to measure how long it takes to run our tests. It's like Inception, but with Jest.
Remember: "Program testing can be used to show the presence of bugs, but never to show their absence!" - Edsger W. Dijkstra (But we can at least make sure those bugs are found quickly!)
All submissions, including submissions by project members, require review. We use GitHub pull requests for this purpose. Consult GitHub Help for more information on using pull requests.
During code review, if you see something that could be improved, don't just say "This could be faster." Instead, submit a pull request to make it faster. Be the change you want to see in the codebase.
Remember, code tells you how, comments tell you why. Please document your code as if the person who ends up maintaining it is a sleep-deprived developer who knows where you live. And remember, that person could be you after a long night of debugging webpack config files.
We're all about that F5 Experience, remember? If your code takes longer to run than it takes to brew a cup of coffee, it's probably not fast enough. Profile early, profile often. Your future self (and your future caffeinated self) will thank you.
Remember, in JavaScript development, there are only two types of projects: those that are measuring their build times, and those that are still waiting for webpack to finish. Let's strive to be the former!
Happy coding, and may your builds be ever faster! 🚀