Easy way to use forked packages
mitar opened this issue · 11 comments
Currently there is no easy way to operate from a GitHub fork of a package. So imagine that I would have a package and would like to modify it a bit, just to see if it works better/fixes the problem (but still collaborate with other team members through git). I cannot make a fork on GitHub and link that as a dependency. I can only make a submodule in packages directory. But then, if package defines package name, or uses that anywhere as a dependency (for tests), I have to rename the package as well everywhere in the code. This is cumbersome and require unnecessary changes to the package repository.
Interesting. Didn't know about PACKAGE_DIRS. :-)
But what I am concerned with is working together with others. I cannot ask everyone in a team to setup PACKAGE_DIRS every time I would like to push a (temporary) fork of a package. They should just update repository and it should work for them.
?? @mitar you've been here forever and didnt know about PACKAGE_DIRS? :)
(its the reason why I never used mrt...)
:-))) That's why it is great to have amazing people around me to teach me new things every day. :-)
I love mrt and I am still using it. :-) It really makes it easy to have forked versions during development: https://github.com/peerlibrary/peerlibrary/blob/meteor0.9.0/smart.lock
I see, as you're pointing out, the thing is that now you can have user:package#1.0.0_rcX releases but this cannot fit into other packages deps unless you have a full stack of rc releases.
as for the PACKAGE_DIRS one might think about having a local alias for PACKAGE_DIRS='...' meteor called meteor_local or whathever so to get a quick meteor run picking up local packages instead of mainstream ones.
But the easiest thing might be using a clone of the package repository just under myProject/packages (without changing its version number inside package.js) so that it will be picked up in place of the one currently published and all other dependencies as well as dependants will continue to be correctly detected.
There's an open issue about spreading this techniques a bit more directly on atmosphere, but I agree that a more official way to have an more direct way to test modification to packages might improve the workflow of many developers.
+1
And one has to put package repository under myProject/packages inside a directory with the same name as the package itself is, yes?
whatever name you prefer for the folder!
It can also be a complete different one...
I'm quite sure meteor is doing a pre-scan of all folders under packages evaluating all package.js files found therein to start the Version Solver
I think forking packages is already on the mdg todo?
(I think ekatek mentioned at some point)
Actually I think the problem is only for core package that are used as a dependency of other core packages (like jquery or tracker). There is currently no issue in using mquandalle:stylus instead of the core version.
It is, if mquandalle:stylus does not define its own name, and you clone it into some other directory, and not mquandalle:stylus.