[SOLVED] Proper repository structure

(George Dimitriadis) #1

Hello,

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 :

/Packages/*
!/Packages/Sites
/Packages/Sites/*
!/Packages/Sites/Vendor.Site

But, is there a more preferred way to do this ?

Thanks in advance !

(Benjamin Klix) #2

We only use this:

/Packages/*
!/Packages/Sites

This should be enough.

(George Dimitriadis) #3

Hey @BenjaminK,

that will include Neos.Demo into the repository though.

(Benjamin Klix) #4

Sure, but Neos.Demo should not be part of your Structure when you want to use it for production. Neos.Demo is just for demonstration.

(George Dimitriadis) #5

Hmmmm, but this plugin: Listable, is forcing me to activate Neos.Demo. Or perhaps I should include that plugin into my site’s composer.json instead of the root composer.json ?

I also noticed Sandstorm suggests the same installation method at step 2 (include into the site’s composer). Is this how it should be for all dependencies ?

(Aske Ertmann) #6

Listable doesn’t require Neos.Demo in any way.

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.

(George Dimitriadis) #7

@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 ?

  1. git clone repository-uri
  2. composer install inside the root and inside the site directories
  3. Copy Settings.yaml.example to Settings.yaml and configure the new host credentials in /Configuration directory.
  4. Copy the database into the new host database
(Aske Ertmann) #8

The flowpack/neos-frontendlogin doesn’t require neos-demo either. See https://github.com/Flowpack/Flowpack.Neos.FrontendLogin/blob/master/composer.json

If you have the neos.demo it’s likely because it’s in the root composer.json, remove it using composer.

A package depends on another package by adding it to it’s composer.json, here’s an example of depending on Neos.Seo https://github.com/neos/Neos.Demo/blob/master/composer.json#L9

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.

(George Dimitriadis) #9

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.

Sounds good

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.

(Aske Ertmann) #10

Because the loading order of the package (influencing configuration/fusion code) is determined on the packages composer.json and does not take the root composer.json into account.

(George Dimitriadis) #11

Hey @aertmann,

Alright, but I am still confused about where this functionality comes from. Is this a Neos feature ? Meaning, Neos checks each package’s composer.json for loading order ?

(Aske Ertmann) #12

Flow (the underlying framework Neos is built upon) uses composer internally for package loading, so yes it’s core behavior and it does.

(George Dimitriadis) #13

Alright, this makes more sense now, thanks a lot for your explanation !

(George Dimitriadis) #14

Just to update, this is my “deploy script” for updating the remote with new changes:

#!/bin/bash

# Make sure the flow commands run for Production context
export FLOW_CONTEXT=Production

# Update the current branch with the latest changes
git add --all
git reset --hard
git pull

# Get any new composer dependencies
composer install

# Migrate database changes
./flow doctrine:update
./flow doctrine:migrate

# 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
./flow flow:package:rescan

# Fix affected nodes
./flow node:repair

# 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.