These are chat archives for reactioncommerce/reaction

12th
Jun 2015
Michael Jenny
@prinzdezibel
Jun 12 2015 13:11 UTC
I have some custom templates in my main reaction package. It works fine when working locally (meteor run). But the modified files are not there when I bundle the application with meteor build .. Am I supposed to declare my files in a meta file (packages.json or so ) ??
Aaron Judd
@aaronjudd
Jun 12 2015 15:16 UTC
@prinzdezibel nope, I don’t think so. meteor build should include everything - I’ve released with custom packages in packages/ as well (in addition to just customizing the app)
anything in the app reaction/* should get included. anything that is physically in packages/* will get included (but not if it is a symlink)
Michael Jenny
@prinzdezibel
Jun 12 2015 15:21 UTC
I tried it with a new plain reaction checkout. It works as expected. Also the customised footer.html in there is packaged. Must have something to do with my application..
It is also packaged, as I've figured out. But the template is not rendered. don't know why. but also some links (sign in) are not working and footer is not shown. Even though I didn't mess with that. I'll start over again..
Aaron Judd
@aaronjudd
Jun 12 2015 15:26 UTC
i’m just wondering if you’re working with a modified core-theme package local, when you build maybe it’s pulling a published vs a local one? (or that could be true with some other package)? if meteor doesn’t see the package local it will pull from published so something could be out of synch there (the latest core-theme from development isn’t published yet)
Michael Jenny
@prinzdezibel
Jun 12 2015 16:03 UTC
@aaronjudd I think it has to do with my symlinked reaction-core package in /packages
without it my app does not work properly
How can I get these packaged as well when doing a 'meteor build' ? (Besides doing a cp -R)
Maybe I should checkout directly in <app>/packages ?
Aaron Judd
@aaronjudd
Jun 12 2015 16:10 UTC
yes, you can physically store the checkout in packages/ that will work
Michael Jenny
@prinzdezibel
Jun 12 2015 16:17 UTC
@aaronjudd Do you know the problem when developing under osx and deploying with linux you may run into problems with binary dependencies, specifically with bcrypt, npm-node-aes-gcm and bson ?
I always need to do something along the lines:
npm install bcrypt
cp -r node_modules/bcrypt npm/npm-bcrypt/node_modules/
in bundle/programs/server
Aaron Judd
@aaronjudd
Jun 12 2015 16:18 UTC
when you do ‘meteor publish’ you have to deploy across 4 different machines - each of the binary dependencies gets recompiled for each architecture, so you should not need to do that
Michael Jenny
@prinzdezibel
Jun 12 2015 16:19 UTC
I dont use meteor publish, maybe that's my problem. I use meteor build and then extract that tarball on my server.
Aaron Judd
@aaronjudd
Jun 12 2015 16:19 UTC
on windows npm-node-aes-gcm needs some manual installation (npm, openssl) before use
Michael Jenny
@prinzdezibel
Jun 12 2015 16:19 UTC
Is that not the way to go?
Aaron Judd
@aaronjudd
Jun 12 2015 16:20 UTC
nah, I wouldn’t do the publish (since that’s publishing to atmosphere) - just saying that packages that you have as dependencies should include the correct binaries for where you are building
you might want to build on a linux box, if that’s where you are distributiung though
the meteor publish tool actually spins up boxes for each architecture, so you sort of need to replicate that in your manual build
Michael Jenny
@prinzdezibel
Jun 12 2015 16:21 UTC
how do you handle this? Do the build on the target platform??
Aaron Judd
@aaronjudd
Jun 12 2015 16:21 UTC
yes
Michael Jenny
@prinzdezibel
Jun 12 2015 16:21 UTC
You do also development with osx, right?
Aaron Judd
@aaronjudd
Jun 12 2015 16:21 UTC
and it’s a PiTA
yes
Michael Jenny
@prinzdezibel
Jun 12 2015 16:22 UTC
understand
Michael Jenny
@prinzdezibel
Jun 12 2015 20:21 UTC
why are the files under reaction/client/themes ignored by .gitignore? Aren't the *.import.less files meant for user modifications?
I mean, I cloned the package and used it as a starting point. So from now on I want my upstream repository to change to my own and not use the reaction remote anymore, right?
Is there a good practice how to deal with that?
Aaron Judd
@aaronjudd
Jun 12 2015 20:35 UTC
@prinzdezibel they are ignored just so you can edit them and not have to deal with conflicts. They are -re-generated by core-theme only if they don’t exist.

build or publish doesn’t pay any attention to .gitignore, so your changes should be included in any build or deploy

fyi in 0.6.0(development) I moved them to client/themes/bootstrap to make room for multiple themes

Michael Jenny
@prinzdezibel
Jun 12 2015 20:36 UTC
Ok, but workflow would be like this (correct me, if you have another one).
  1. clone
  1. create own remote repository
modify
push to own remote
  • go to server
  • pull from remote again
  • and build
so I need it under source control again.
At least the .import.less files that are meant for user modification
Aaron Judd
@aaronjudd
Jun 12 2015 20:40 UTC
well I guess you could remove them gitignore just for your repo. I also have a helper for rebuilding them bin/docker/build-themes.sh
because they will only generate the .less files in a development environment (so if they aren’t there in production build you are out of luck)
Michael Jenny
@prinzdezibel
Jun 12 2015 20:40 UTC
aha. that is exactly what I have realized.
That was one weird ! I didn't understand why my theme is not generated on the server
Aaron Judd
@aaronjudd
Jun 12 2015 20:41 UTC
so if you used that in your deploy - checkout, use that script, then build (take a look at the circle.yml in reaction-core)
so normally I figure people would deploy straight from their dev build locally and have the .less files already (so they probaby would modify those and not core-theme). but if you modify core-theme you need to do something like my script trick
Michael Jenny
@prinzdezibel
Jun 12 2015 20:44 UTC
Ok. I will have a look into build-themes.sh
thank you
Aaron Judd
@aaronjudd
Jun 12 2015 20:44 UTC
:thumbsup: