meteormeteorite

How to fork an existing Meteorite package in a clean way?


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.

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 meteor-router as an example:

  1. Simply copy the package files into your packages folder ==========================================================

Steps:

Advantages:

Disadvantages:

Do not even consider this for any but the simplest packages!

  1. Fork on github, then ... ===========================

To fork a package on github, your can check your smart.lock file to see which repository is being used. Go to the github page of that repository and fork it.

Next, you have three options:

2a. Add it as a git submodule

More info on git submodules: http://git-scm.com/book/en/v2/Git-Tools-Submodules

Steps:

Advantages:

Disadvantages:

2b. Edit your project's smart.json to use your version

Steps:

Advantages:

Disadvantages:

(Suggested Meteorite improvement: allow packages to be installed in an editable form, like Python's pip allows using the '-e' parameter)

2c. Clone outside of your project and add a "path" to smart.json

Steps:

Advantages:

Disadvantages:


Which method do you use? How do you work around the disadvantages to that method?

I might have missed some issues with these solutions.


Solution

  • 2b. Edit your project's smart.json to use your version

    I would recommend this version, as it is the most consistent with how the smart.json was intended to be used and supported. mrt update will correctly reflect the latest from the git repo I think.