First off, thanks for taking the time to contribute! 🎉 👍

To build and run the extension follow these steps.

1. Clone the repository.
2. Make sure Yarn is installed.
3. Run yarn install to setup the project and install all required dependencies.
4. Start hacking. If you're adding a plugin, you may be interested in seeing the commits that add these plugins:
   • CSS
5. Build and load the extension:
   • Firefox (Quickstart):
     1. yarn firefox-open
   • Chrome (Quickstart):
     1. yarn chrome-open
   • Chrome (Long Version):
     1. To build the extension once run yarn build or yarn watch during development.
     2. Load extension https://developer.chrome.com/extensions/getstarted#unpacked.

Every single file on GitHub.com is represented by a blob. A blob consists of many attributes. One of these attributes is a reference to the blobs DOM node. The plugin will tweak this DOM node and turn static strings into clickable links. How does this work? There is an npm module for that. It's called findandreplacedomtext and it searches for regular expression matches in a given DOM node and wraps each match with a link node.

If a user clicks on a link, the associated plugin will be called and returns an array of urls. For every url a HTTP HEAD request is made (to determine if the resource is available or not) until one was successful. Finally, a redirect will be invoked. That’s it.

The outline above is an extremely simplified version. In real life you have to deal with a lot of edge cases. If you are interested in some of these edge cases check out the npm-manifest plugin and the javascriptUniversal resolver.

• Please check to make sure that there aren't existing pull requests attempting to address the issue mentioned. We also recommend checking for issues related to the issue on the tracker, as a team member may be working on the issue in a branch or fork.
• Non-trivial changes should be discussed in an issue first
• Develop in a topic branch, not master
• Lint the code by yarn lint
• Add relevant tests to cover the change
• Make sure test-suite passes: yarn test
• Document any new features in README.md
• Squash your commits
• Write a convincing description of your PR and why we should land it

• Update the version number in packages/core/package.json and assets/manifest.json. Use minor or major instead of patch if needed (see semver.org for details). Consider that non-patch releases will cause users to receive update notifications, so lean towards a patch release for platform-specific stuff. See lib/notification.js.
• Open a pull request with the new version.
• Once the pull request is merged in, tag the resulting commit as vX.Y.Z (where X, Y, Z are the major, minor, and patch versions).
• Push the tag to GitHub. This will trigger Travis CI to create a new GitHub Release and submit the new Chrome extension to the Chrome Web Store. See .travis.yml for details.
• Submit firefox-octolinker-X.Y.Z.zip from the GitHub Release to addons.mozilla.org. Be sure to include the Source code (zip) file from the release as well.
• Submit opera-octolinker-X.Y.Z.zip from the GitHub Release to addons.opera.com. Afterwards, go to the Conversation tab, add a link to the Source code (zip) file and copy/paste the build instructions from previous releases.
• Update release notes at https://github.com/OctoLinker/OctoLinker/releases/tag/vX.Y.Z. You can find a list of changes since the previous release at https://github.com/OctoLinker/OctoLinker/compare/vA.B.C...vX.Y.Z, where A.B.C is the previous version number. Consider that non-patch releases will cause users to receive update notifications showing the first line of the release notes. See lib/notification.js.