Skip to content

Latest commit

 

History

History
77 lines (51 loc) · 4.58 KB

CONTRIBUTING.md

File metadata and controls

77 lines (51 loc) · 4.58 KB

Contributing to agoda-devfeedback

First off, thanks for taking the time to contribute! You're already faster than a webpack build on a cold start! 🚀

The Zen of JavaScript Metrics

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!

Project Structure

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).

The F5 Experience

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:

  1. 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".
  2. Fast Feedback Loop: We want our builds and tests to run faster than a promise resolves. If you find yourself waiting, something's wrong.

Pull Request Process

  1. 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.
  2. 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.
  3. 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!

Code of Conduct

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.)

Testing

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!)

Code Review

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.

Documentation

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.

Performance

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.

And finally...

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! 🚀