Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"sister repo" approach best practice - fortawesome:fontawesome #16

Open
dandv opened this issue Mar 29, 2015 · 9 comments
Open

"sister repo" approach best practice - fortawesome:fontawesome #16

dandv opened this issue Mar 29, 2015 · 9 comments

Comments

@dandv
Copy link
Contributor

dandv commented Mar 29, 2015

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
Copy link
Contributor Author

dandv commented Mar 29, 2015

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
Copy link

benjick commented Mar 29, 2015

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

@splendido
Copy link
Member

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
Copy link
Member

@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... ;-)

This was referenced Apr 16, 2015
@splendido
Copy link
Member

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
Copy link
Member

@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
Copy link
Contributor Author

dandv commented Jun 22, 2015

Could we do without gulp, but use npm instead?

@splendido
Copy link
Member

Open to "easier" solutions!

@splendido
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants