Open dandv opened 9 years ago
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?
I used the same method the other day; https://github.com/benjick/meteor-webcam, does it look okay?
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?
@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... ;-)
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!
@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.
Could we do without gulp, but use npm instead?
Open to "easier" solutions!
at the moment, once you've cloned a local version of the repo. The spets needed to update the package are:
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
@splendido, how can we integrate this with autopublish?