Skip to content

Development workflow

Jump to bottom
Tom J edited this page Apr 13, 2022 · 2 revisions

Local development

Use vscode, else you'll likely run into trouble with our linter and will have to fix your code after pushing it to CI, instead of having vscode fix it automatically for you as you type.

When using vscode, make sure to open the project using the flowcrypt-browser.code-workspace project file. This way TSLint will tell you when you do things wrong and help you fix it.

What I do: When I changed enough code and want to see it in action, I hit F5. F5 in my vscode is mapped to build task which is mapped to npm run-script build-incremental. I have a browser open on second monitor to work with the results. Assuming you have used the "load unpacked" button in chrome:

  • to see a new version of an extension page, just hit F5 like you would on a web site. You do not need to reload the extension, just the page.
  • same thing for iframes embedded in Gmail. These are also extension pages, but instead of hitting F5 and reloading the whole tab, you can right click the iframe and choose "reload frame". No need to reload extension.
  • If you need to see changes in content scripts or background page, you need to reload the extension using the "reload" button on chrome://extensions after each change

Git workflow

  1. I recommend to create a Draft PR right after the first useful commit (github allows you to create a Draft PR instead of a normal PR)
  2. continue working on your branch, which will automatically update the Draft PR. @tomholub or someone else may chip in with some comments. The point is to have a discussion about the direction of the code rather earlier than later, especially for complex issues. For small fixes this doesn't matter much.
  3. when you feel the PR is ready to be merged and tests pass, you mark it as Ready for review and you request a review from me
  4. @tomholub reviews it, and if no changes are requested, he will squash-merge the PR. Because PRs alsways get squash-merged when merging, you don't have to worry about how many commits you have in your branch, or that every commit is perfect or anything like that. What matters is the end result, which will get squashed to a single commit on master when merging.
  5. master branch will be collecting these squashed PRs as commits over time, and eventually @tomholub decides to release a new version, add a version update commit and run a script to release it to firefox/chrome web store.

Force-pushing into any branches, including your own, is discouraged because it makes it harder to review branches that were force-pushed. Every time you force-push, the person who already reviewed your code previously now has to review everything again instead of looking at the delta. Rebasing is also discouraged for the same reason. Instead:

  • if you made a mistake in last commit: make another commit that undoes the mistake
  • to incorporate latest master: git checkout master && git pull && git checkout issue-1234-my-branch && git merge master && git push

All of the busywork commits on your branch will end up getting squash-merged, so you don't need to worry about messy branch history.

Clone this wiki locally