This guide attempts to make it easy for volunteer contributors and the core team to contribute to and publish Capacitor. Please let us know if there's something missing!
The Capacitor repo uses GitHub issues and discussions to track bugs and feature requests, as well as to provide a place for community questions, ideas, and discussions.
- When to use issues:
- To report specific, reproducible bugs.
- To propose detailed feature requests.
- When to use discussions:
- To ask for help.
- To ask general questions.
- To show off cool stuff.
- To propose ideas for improvement.
- If you think you found a bug, but may need help to further uncover it.
- Anything else! 🌈
When reporting bugs, we ask you to provide a minimal sample application that demonstrates the issue. Without a reliable code reproduction, it is unlikely we will be able to resolve the issue, leading to it being closed.
To create a code reproduction:
- Create a new application using
npx @capacitor/cli create(orionic start --capacitor). - Add the minimum amount of code necessary to recreate the issue you're experiencing.
- Push the code reproduction to a public GitHub repository and include a link when you create a bug report.
- Be sure to include steps to reproduce the issue.
Before working on Capacitor, it's important to understand the philosophy behind the project to avoid investing time in things that won't fit into the goals of the project.
Please read @maxlynch's essay How Capacitor Works for a deep dive into the project and its goals.
- Check out this repository.
- Read and follow
example/README.md
For any large changes, make sure you've consulted with the team first. One way to do this would be to create a draft PR for discussion, or bringing up the discussion in the Capacitor slack.
To achieve Capacitor's goal of being stable and easy to upgrade, we would like to avoid unnecessary third party libraries as much as possible. Before embarking on Capacitor contributions, make sure you aren't planning on introducing third party libraries without consulting with the team first.
On native, that means avoid adding any new Cocoapod or Gradle dependencies without explicit approval. If you just need a small bit of functionality from that library, consider adding an implementation to the codebase directly.
On web, this means do not add any third party libraries such as Firebase or Lodash. Strive for implementations that use pure Web APIs even if it means more work.
The ionic-team/capacitor repo is a monorepo containing all of the standard Capacitor components. The current directory structure looks like this:
app-template: The default app template used duringcreatecli: Capacitor CLI/Build scriptscore: Capacitor Core JS libraryios: Capacitor iOS Runtimeios-template: Default iOS App installed by the CLIandroid: Capacitor Android Runtimeandroid-template: Default Android App installed by the CLIexample: Example project for developmentplugin-template: The default plugin template when creating a new pluginscripts: publish and task scripts
Capacitor packages are published together with a fixed version using Lerna.
To publish Capacitor, run the following:
npm run publish