title: How to fork an existing Meteorite package in a clean way?
body: <p>I'm trying to figure out the best/cleanest way to fork an existing package on Atmosphere within a project. I encountered a few occasions where an existing package needed some modifications and I was forced to fork it.</p>
  
  <p>As far as I can tell, the following options exist. Unfortunately, all of these have their own issues and I have yet to find the perfect solution. I will use <code>meteor-router</code> as an example:</p>
  
  <h1>1. Simply copy the package files into your packages folder</h1>
  
  <p>Steps:</p>
  
  <ul>
  <li>remove <code>packages/router/.git/</code></li>
  <li>edit <code>packages/.gitignore</code> and remove the 'router' line</li>
  <li>remove router from your <code>smart.json</code></li>
  <li>add <code>packages/router</code> to your project repository and commit</li>
  <li>now make changes (this way your initial commit is a clean version and you can work out what you have changed yourself)</li>
  </ul>
  
  <p>Advantages: </p>
  
  <ul>
  <li>easy to achieve and understand</li>
  <li>all the code you rely on can be found in your project repository</li>
  </ul>
  
  <p>Disadvantages:</p>
  
  <ul>
  <li>you lose all the original repositories history</li>
  <li>it's hard to update to a newer version</li>
  <li>it's hard contribute your changes back to the original project</li>
  </ul>
  
  <p>Do not even consider this for any but the simplest packages!</p>
  
  <h1>2. Fork on github, then ...</h1>
  
  <p>To fork a package on github, your can check your <code>smart.lock</code> file to see which repository is being used. Go to the github page of that repository and fork it. </p>
  
  <p>Next, you have three options:</p>
  
  <h2>2a. Add it as a git submodule</h2>
  
  <p>More info on git submodules: <a href="http://git-scm.com/book/en/Git-Tools-Submodules" rel="noreferrer">http://git-scm.com/book/en/Git-Tools-Submodules</a></p>
  
  <p>Steps:</p>
  
  <ul>
  <li>See the link above about how to init/create/update a submodule</li>
  <li>Remove the package from your <code>smart.json</code></li>
  </ul>
  
  <p>Advantages:</p>
  
  <ul>
  <li>Submodule versions are connected to your project</li>
  <li>Changes are immediately picked up</li>
  </ul>
  
  <p>Disadvantages:</p>
  
  <ul>
  <li>All developers need to run <code>git submodule init</code> the first time and <code>update</code> to update</li>
  <li>You have to be aware of the issues with submodules when editing the checkout</li>
  <li>Read about other issues with submodules</li>
  </ul>
  
  <h2>2b. Edit your project's <code>smart.json</code> to use your version</h2>
  
  <p>Steps:</p>
  
  <ul>
  <li>In your <code>smart.json</code>, find <code>"router": {}</code> and add <code>"git": "https://github.com/USER/meteor-router.git"</code> inside the empty <code>{}</code>. </li>
  <li>Optionally, add a <code>"branch"</code> or <code>"tag"</code>.</li>
  </ul>
  
  <p>Advantages:</p>
  
  <ul>
  <li>You can still use Meteorite to manage your external packages</li>
  <li>Will work automatically for other developers and in deployment environments</li>
  </ul>
  
  <p>Disadvantages:</p>
  
  <ul>
  <li>The code in your packages folder is not editable, as it's not a git repository</li>
  <li>Meteorite will not automatically update to the latest version every time your run it</li>
  </ul>
  
  <p>(Suggested Meteorite improvement: allow packages to be installed in an editable form, like Python's pip allows using the '-e' parameter)</p>
  
  <h2>2c. Clone outside of your project and add a <code>"path"</code> to <code>smart.json</code></h2>
  
  <p>Steps:</p>
  
  <ul>
  <li>Clone the package to a place outside of your project</li>
  <li>Similar to 2b, add a <code>"path"</code> to your <code>smart.json</code> to point Meteorite to your local checkout</li>
  </ul>
  
  <p>Advantages:</p>
  
  <ul>
  <li>You can edit the package at will and Meteor will automatically pickup the changes.</li>
  </ul>
  
  <p>Disadvantages:</p>
  
  <ul>
  <li>If you commit this <code>smart.json</code>, you will most likely break all other development/deployment environments...</li>
  </ul>
  
  <hr>
  
  <p>Which method do you use? How do you work around the disadvantages to that method?</p>
  
  <p>I might have missed some issues with these solutions.</p>