First, thank you for considering contributing to rollup! It's people like you that make the open source community such a great community! 😊
We welcome any type of contribution, not only code. You can help with
- QA: file bug reports, the more details you can give the better (i.e. REPL-links or repos that demonstrate the specific issue)
- Marketing: writing blog posts, howto's, printing stickers, ...
- Community: presenting the project at meetups, organizing a dedicated meetup for the local community, ...
- Code: take a look at the open issues. Even if you can't write code, commenting on them, showing that you care about a given issue matters. It helps us triage them.
- Money: we welcome financial contributions in full transparency on our open collective.
Working on your first Pull Request? You can learn how from this free course, How to Contribute to an Open Source Project on GitHub.
With npm run test you can run all tests together.
To save time for quick iterations, you can add solo:true to the _config.js file of any given test to run just this one test. To further speed up rebuilds, note that most tests just need the CommonJS build of Rollup.
For those tests, it is enough to run
npm run build:cjs
npm run test:quick
Note that this does not run the browser tests and a few CLI tests will fail.
Running
npm run devwill start the website locally in development mode via Vite. This will give you a live preview of the documentation. It will also verify that the documentation does not contain any dead links.
A special feature of the website is that the REPL at http://localhost:5173/repl/ is directly using the browser build of your local copy of Rollup created via Vite. It even supports full hot module replacement, which means that when you change anything within Rollup, the REPL will automatically rebundle the current code using your latest changes. This can come in very handy when working on a bug or tree-shaking improvement to allow extremely fast iterations.
Any code change should be submitted as a pull request. The description should explain what the code does and give steps to execute it. The pull request should also contain tests.
The bigger the pull request, the longer it will take to review and merge. Try to break down large pull requests in smaller chunks that are easier to review and merge.
It is also always helpful to have some context for your pull request. What was the purpose? Why does it matter to you? Does it resolve any known Github issues? Adding a line "resolves #" (e.g. "resolves #23") to the description of your pull request or of a specific commit will automatically close this issue once the pull request is merged.
We also welcome financial contributions in full transparency on our open collective. Anyone can file an expense. If the expense makes sense for the development of the community, it will be "merged" in the ledger of our open collective by the core contributors and the person who filed the expense will be reimbursed.
If you require technical assistance, Stackoverflow or Discord are usually the best places to start. You can also create an issue (protip: do a quick search first to see if someone else didn't ask the same question before!).
Thank you to all the people who have already contributed to rollup!
Thank you to all our backers! [Become a backer]
Thank you to all our sponsors! (please ask your company to also support this open source project by becoming a sponsor)
