Frontastic coding guide

When working with Frontastic you can, in general, follow your own coding guidelines. However, some rules are needed for your code to function properly with Frontastic which we'll go through in this article. On top of that, we recommend some additional guidelines which will help you streamline your development workflow with Frontastic.

GIT workflow

Frontastic automatically builds pushes to the master branch. Those builds will be tested and, if successful, compiled assets will be available for deployment.

This doesn't mean that you can't use branches. However, branches will only be tested when pushed to the remote origin and no assets will be compiled (see the deployment article for more information).

Any successful master build will also automatically be deployed to staging (if you didn't explicitly request this to be turned off) and be available for rollout to production through the Frontastic studio.

Useful tips

Frontastic suggests a ‘master-based development flow’ (originally known as ‘trunk-based development’). This means branches are generally discouraged. All code should go directly into master. This requires each push (ideally each commit) to leave the codebase fully functional. Feature flagging and branch-by-abstraction are programming techniques to make this possible. With that, your team will benefit from a faster, more agile development workflow.

We also suggest following these rules for a smooth setup:

Pull before you push
Rebase unpushed changes in favor of merge (set pull.rebase globally to true)
Structure your work in logical steps and commit parts of your work together which deal with a common purpose
Frequent, smaller commits are preferred over large batches of work
Push frequently, but always ensure a working state in master

Organizing code

Code in Frontastic projects and your customer directory should be organized as follows:

src/ contains all source code divided by programming language
test/includes all tests in the same structure as used in src/
config/ holds the global project configuration
public/ is publically accessible through the web server and should only contain the main code entry points & assets
node_modules/ and vendor/ are used to install project specific code dependencies using Yarn (for JavaScript) and Composer (for PHP)

Testing and code verification

Frontastic comes with a build system that allows you to run all steps within a Frontastic sandbox. To run all tests of all of your projects you can SSH into the sandbox and run the below command:

ant test

This will execute dynamic tests for JavaScript and PHP code as well as code style checks and other inspections. You can adjust what exactly is tested by editing settings in the environment file or adjusting build.xml (see the extending the build system article for more information).

PHP coding conventions

The following conventions are strongly advised to be applied to PHP backend code.

Basics

The following PSR (PHP Standardization Request) must be followed:

PSR-1: Basic coding standard
PSR-2: Coding style guide
PSR-4: Autoloader

Besides that, we're using Symfony 4.1 in all of our PHP-based components and attempt to follow its rules.