"sister repo" approach best practice - fortawesome:fontawesome

[dandv]

I've just finished revamping the Font Awesome integration to use the "sister repo" approach that @splendido and I have been discussing for a while.

Advantages

• We clone the 3rd party library as a git submodule. The original author doesn't have to accept any Meteor files in their repo.
• We can have as many additional files as we need: tests, examples etc.
• The version is obtained automatically and robustly from the library's package.json, and failing that, from GitHub, then NPMJS
• Tests and publishing are driven in a standard way, from the "scripts" section in package.json for cross-platform compatibility (thanks to Gerard Saychay for the post on npm scripts)

@splendido, how can we integrate this with autopublish?

[dandv]

Hey @splendido, I tried to activate autopublish but it can't parse package.js. Can you take a look please?

PS: I also suspect we'll need to ensure that the submodule is updated. Maybe it's easier to change your request to ask just for a webhook?

[benjick]

I used the same method the other day; https://github.com/benjick/meteor-webcam, does it look okay?

[splendido]

hey @dandv, I've been out all week: sorry for the late reply!

I'll try to make a step forward with autopublish during next days!
...if you recall, I suggested to don't even have a git submodule inside the repo but just cloning the upstream repo into its "sister" one during publishing.
I see this much easier rather than having to keep the submodule up to date: do you think this would be a problem?

[splendido]

@dandv, at the moment autopublish is not able to parse package.js files using Npm tricks to load package's version and name.
I actually see it hard to achieve this... :(

This is basically why I'm for a small build task to be included into the "sister" repo to update the package's version... ;-)

[splendido]

Hei @dandv,
this is what I had in mind for the sister repo :)

Lets try to clone the repository and run sh publish.sh (which contains the commands autopublish.meteor.com would run on the build machine to actually publish the package...)

...if it makes sense, I can try adding another different publish flow to target this new scenario.
Let me know what do you think!

[splendido]

@dandv, should we convert fontawesome wrapper to the new style "sister repo approach"?

See jspdf-core-wrapper which uses no git submodules and has a gulp file to deal with the upstream repo.

[dandv]

Could we do without gulp, but use npm instead?

[splendido]

Open to "easier" solutions!

[splendido]

at the moment, once you've cloned a local version of the repo. The spets needed to update the package are:

• npm install
• gulp getUpstream --tag v2.4.3
• gulp test
• gulp updateVersion --tag v2.4.3
• gulp updateRelease --tag v2.4.3
• git commit -am 'Bump to version 2.4.3'
• git push
• meteor publish