Contributing to Tab Stash
Tab Stash has adopted the Contributor Covenant Code of Conduct. Anyone participating in the Tab Stash community, whether they are writing code, filing bugs, or simply posting questions, is asked to follow these standards.
In short, before posting please ask yourself: “If this were directed at me, how would it make me feel?” If the answer is negative, think carefully about how to re-frame your post—try to focus on specific, observable facts, avoid generalizing, and replace emotional language (“this was a huge problem”) with concrete details (“it took me an hour to recover my data because…”).
First of all, thanks for your interest in contributing to Tab Stash! The best way to get your new feature or bugfix included is to open a pull request in GitHub. Please make sure you’ve read and followed the Code Style section below, and included adequate comments and notes in your commit message for reviewers to understand what you’re trying to do and why.
Importantly, don’t expect your pull request to be merged right away. You will likely get at least one round of constructive feedback; this is to help catch bugs and ensure the code stays maintainable for the next person who wants to contribute. I hope you will take this feedback in the spirit in which it’s given–as reflecting our shared desire to make Tab Stash the best it can possibly be.
Getting the Source Code
Tab Stash’s source code is available on GitHub.
Building Tab Stash for Development
You’ll need a UNIX-like system (e.g. Mac or Linux) to build Tab Stash–unfortunately, building on Windows is no longer supported due to the multiple build steps involved (although patches to make the build more cross-platform are welcome). To build, you’ll need the following installed:
- GNU Make, Git, patch, and rsync
- A recent version of Node.js
- Inkscape must be installed such that the
inkscapecommand-line tool is available in your PATH (GUI version is not required unless you want to use it to edit the icons)
To build and run tests, all you have to do is run
on a multi-core system):
The result will be in the
dist directory. You can load it into your Firefox
by following these steps:
- Open a new tab and go to
- Click on “This Firefox” in the sidebar.
- Click “Load Temporary Add-on”.
- Browse to the
distdirectory, and select the
An experimental port to Chrome is also built in
Building Tab Stash for Release
Release builds may only be done in a clean tree with no uncommitted changes, and
your HEAD commit must be pointing at a release tag (or
make will create one
for you with the version listed in
manifest.json). In the top-level
tab-stash directory, run:
$ make [-jWHATEVER] rel
All generated files in
dist will be rebuilt, with debugging information and
code stripped. Two package files will be generated, both of which can be
uploaded to addons.mozilla.org–the first,
tab-stash-X.Y.zip, is the actual
extension. The second,
tab-stash-src-X.Y.tar.gz, is the source to go along
- Indentation: Four spaces (no tabs) per indentation level.
- Line Length: No lines should be longer than 80 columns.
- When wrapping, please line up your wrapped line with the relevant opening ‘(‘ or ‘[’ on the previous line. (Emacs does this correctly by default.)
- If there’s no grouping character to line up with, indent wrapped lines an additional four spaces.
- Comments: Where it’s not immediately obvious, please write comments
explaining why your code is doing what it’s doing. Use
- Variable Names: Use your best judgment–the larger the scope, the more
descriptive the name should be. Single-letter variable names are fine if the
contents/usage of the variable are obvious in context and the variable’s scope
fits on a single (small) screen.
- Constants are written
- Class Names are written
- Function and Argument Names are written
likeThisfor arguments and public functions or
like_thisfor private functions.
- Local Variable Names are written
constfor local variables when possible, or
letwhen necessary. Don’t use
- Constants are written
The existing code does not always follow these guidelines consistently; if you find inconsistencies, please feel free to correct them (but please submit corrections in commits which are separate from functional changes).