These are chat archives for reactioncommerce/reaction

17th
Feb 2015
Aaron Judd
@aaronjudd
Feb 17 2015 00:17
@evliu console
Everest Liu
@evliu
Feb 17 2015 00:18
i did that for my register.js
registry: […, {console: ‘someTitle’}]
Aaron Judd
@aaronjudd
Feb 17 2015 00:18
 {
      route: "dashboard"
      label: 'Dashboard'
      provides: 'console'
    }
Everest Liu
@evliu
Feb 17 2015 00:18
ahhh, inside provides
Aaron Judd
@aaronjudd
Feb 17 2015 00:19
:thumbsup:
Everest Liu
@evliu
Feb 17 2015 00:24
hmm, doesn’t seem to be working
i’ll try with the helloworld package
Aaron Judd
@aaronjudd
Feb 17 2015 00:25
don’t forget you’ll need to reset or remove/add the package to refresh those settings
(unless, of course, you are editing in the db)
Everest Liu
@evliu
Feb 17 2015 00:25
ohhh that makes sense
Aaron Judd
@aaronjudd
Feb 17 2015 00:26
I’ll add that to the docs… when you’ve been staring at it for a week it seems obvious lol
Everest Liu
@evliu
Feb 17 2015 00:26
haha, makes sense
Everest Liu
@evliu
Feb 17 2015 03:07
is there a specific tag or commit for reaction-core that the package refactor occured at? need to review a coworkers’ code with the old reaction packaging system
Aaron Judd
@aaronjudd
Feb 17 2015 03:08
this is where the first commit was made to that branch reactioncommerce/reaction-core@78cfb59
Everest Liu
@evliu
Feb 17 2015 03:10
thx. the commit tree was confusing me because there are so many branches and merges
Aaron Judd
@aaronjudd
Feb 17 2015 03:11
open to suggestions...
Everest Liu
@evliu
Feb 17 2015 03:20

the easiest i can think of would be more descriptive commit messages, maybe something like

COMPONENT: message message. #123

where #123 is the related ticket for the commit (since github lets you filter by ticket #, and see all commits attached to it), and on branch merges, short description on what the merge adds/removes/fixes

and squash commits that are related if it doesn’t convolute the git commits (like all the package docs update commits could probably be squashed)
Aaron Judd
@aaronjudd
Feb 17 2015 03:24
yeah, I was thinking about squashing more of those. I’ve been generally a lot more verbose on the commits, in particular the “long message”.
Everest Liu
@evliu
Feb 17 2015 03:27
my personal method is to actually git pull rebase PRs onto a fork of master so all the commits to be merged actually sit on top of master, then after reviewing, i push those onto master, which automatically closes the PR, preserves the actual commits with the author, and so i don’t have any visible merges on master, it just looks like they pushed right onto master on top of the latest commits. that way it looks very linear without a million branches and branch merges
if there are too many conflicts, i have them git pull rebase upstream master and PR to me again
Aaron Judd
@aaronjudd
Feb 17 2015 03:29
I’ve been thinking about using a release branch, that’s a tagged version of development, for that purpose and master would get rebased from there
Everest Liu
@evliu
Feb 17 2015 03:30
yea that would be good
i also push their git pull rebase commits onto upstream master because it makes git bisect much easier too since there were no actual merges, all commits are on the master branch (which is also why i require my PRers to do very clean, logical commits and always tagging an issue #)
oh, and before i push onto upstream, i always source-format their code too ;) i like pretty code that follows formatting rules
Everest Liu
@evliu
Feb 17 2015 03:35
(logical commits also means everything isn’t just pushed up in one commit, i need to see the logical order; commit dependencies or new libraries and utility functions first, then commit any interfaces with stubbed impls if it’s an OOP language, then commit tests, then commit impls)
that way, you almost always get non-breaking changes in every commit. always wire up last after everything is in place
cedric coroir
@cedric-coroir
Feb 17 2015 10:10
/cheers
Aaron Judd
@aaronjudd
Feb 17 2015 14:42
@cedric-coroir cheers!
Aaron Judd
@aaronjudd
Feb 17 2015 18:16
@aldeed thanks you were right… check-arguments is checking what is passed, not what is defined. the docs also say this clearly, somewhere… but now i’ve got it. duh.
cedric coroir
@cedric-coroir
Feb 17 2015 20:08
Hi guys, so i was trying to play around with docker installation of reactioncommerce and went into 2 issues:
1st the meteor SSL package preventing me to see the website on localhost
Following Aaron suggestion, i will push a -e METEOR_SSL env var to bin/entrypoint.sh
Disabling by default the usage of force-ssl package and enabling it if $METEOR_SSL is set
2nd meteor reactioncommerce auto-downgrading in the git development branch
reactioncommerce:core downgraded from 0.5.0 to 0.2.2
Again as Aaron pointed out, the version is forced in the branch .meteor/packages, preventing this downgrad to happen. Looks like an open issue?
Aaron Judd
@aaronjudd
Feb 17 2015 20:11
I’m not sure why the packages are downgrading when doing a “build”, version just running the local works fine.. @aldeed pointed out the functionality to force the build to use a specific version in meteor packages: reactioncommerce:core@=0.4.2. However this was a new problem as of our v0.3.x build, and I haven’t tracked down the cause yet
regarding your first one, I’m thinking of removing force-ssl as a standard package, and relying on bin/entrypoint.sh to inject it as an option for docker builds
Eric Dobbertin
@aldeed
Feb 17 2015 20:32
@aaronjudd cool. FYI, I had that same issue of downgrading packages on build with a different app yesterday. Still don't know exactly why it's happening or how to simply reproduce, but seems clearly to be a problem with Meteor packaging system (or our understanding of it).
Aaron Judd
@aaronjudd
Feb 17 2015 20:59
I’ve got it in the back of my mind looking for the cause… hopefully something shows up because it’s a real pain
Eric Dobbertin
@aldeed
Feb 17 2015 22:17
It might be related to which packages are installed locally, i.e., does it say "Installed" next to the version when you do meteor show. Because I think I forced the new pkg versions to install locally and then the build worked. So maybe build command doesn't try to download missing package versions? Just wild guesses at this point.
Aaron Judd
@aaronjudd
Feb 17 2015 23:59
any opinions on audit-argument-checks? add to the (core) package, but don’t imply it?, or add to the app level and let everyone figure out errors they’ll get integrating other packages? or just leave out?