I was wondering what’s the proper way to structure my repository when working with Neos. The default .gitignore will exclude the Packages directory, which is where my site files reside, so what is the Neos way to do it ? The only way I understand that would work like this is to have a repository for my site files only and then another repository with the composer configuration, including my site and other dependencies, BUT I would like to avoid making two repositories per project.
Right now I just include my site files, by editing the default .gitignore like this :
And yes you should include it in your site’s composer.json, but that’s to ensure the package is loaded before your site if your site package depends on it. However you should still keep it in the root composer.json to install the package in general.
@aertmann, sorry you’re right, the plugin that was requiring neos.demo is ‘flowpack/neos-frontendlogin’
So, if my package depends on the plugin, I include it in both composer.json files and otherwise I just include it in the root composer.json ? And how do you define “depend” on the plugin ? Right now I only have one site and if I install a plugin I will install it only when that site needs it, does that mean I should always include it in both composer.json files ?
Also, what’s the way to go with deployment ? Are the following steps correct or am I missing something ?
git clone repository-uri
composer install inside the root and inside the site directories
Copy Settings.yaml.example to Settings.yaml and configure the new host credentials in /Configuration directory.
In short, all packages you don’t install using composer need to have their dependencies installed globally (root composer.json) and added to the your own packages composer.json files to ensure loading order.
Regarding deployment, sounds about right, but there are better way to automate deployments. E.g. using Surf, search the forum for more answers.
Well, I tested yesterday a composer configuration with and without Flowpack.Neos.FrrontendLogin and that was my conclusion, I’ll do some more test later, maybe I did something wrong.
I’m not sure I understand this line. If my dependencies are installed globally, how does my package’s composer.json affect the order ? I thought it would only affect the order if I had a rule for my package in the global composer.json, but since I am including my package in my repository I don’t have such a rule.
Thanks for your suggestion on Surf, I don’t know what it is, but I’ll take a look.
Just to update, this is my “deploy script” for updating the remote with new changes:
# Make sure the flow commands run for Production context
# Update the current branch with the latest changes
git add --all
git reset --hard
# Get any new composer dependencies
# Migrate database changes
# Update npm packages
(cd Packages/Sites/Vendor.Site/Resources/Private; npm install)
# Build assets
(cd Packages/Sites/Vendor.Site/Resources/Private; grunt build)
# Rescan all packages so that new packages are taken into account
# Fix affected nodes
# Flush all caches
./flow flow:cache:flush --force
However, I probably don’t have the most ideal project structure, since my Packages’ composer.json is not used for anything else other than the package load order and all my dependencies are loaded in the top-level composer.json
In a few cases like database restructure or NodeType migrations you’ll have to do extra steps manually of course. The above script takes care of the most usual updates only.
Make sure to know what every command does before running it, you might not need / want it.