Best practices for production compilation?

[javiervd]

I was wondering what was the best approach to use frontools in production, when using the built in less styles we would just need to run` setup:static-content:deploy` on the server to update compile the less files to css after a deployment, we could use Grunt locally for development and the command above would take care of compiling/copying the files in production.

However with frontools it seems more complicated since there doesn't seem to include a 'server side' library to compile the stylesheets with `setup:static-content:deploy` it looks like we need to have gulp installed in production to run `gulp release` and also `setup:static-content:deploy` to deploy the rest of the resources. Also before we could just ignore the root `dev` folder in production but since frontools uses it for it's config we also need to include this on top of running `npm install` in the `vendor/snowdog/frontools`.

Is this the correct way to do this? It makes sense during development but it can be a pain for production specially using deployment tools.

[Bartek Igielski · Accepted solution]

I don't know if we can call this "best practices", but that's how we are using Frontools on deployment level.

We are using Capistrano, have Node.js and Gulp installed on every deployment server. Path to frontools directory is passed as a deployment variable. Then depends of the store setup, b/c static versioning have to be handled manually, Frontools can't handle it.

Part of config:

languages = fetch(:m2_lang, 'en_US')
php_bin = fetch(:php_binary, 'php')
execute "mkdir -p #{release_path}/pub/static && echo -n  `basename #{release_path}` > #{release_path}/pub/static/deployed_version.txt"
languages.split(' ').each do |language|
    execute "cd #{release_path} && set -o pipefail && #{php_bin} bin/magento --no-ansi --no-interaction setup:static-content:deploy #{language} --exclude-theme Magento/blank --exclude-theme Magento/luma | grep -v --line-buffered '\\.'"
end
execute "echo -n  `basename #{release_path}` > #{release_path}/pub/static/deployed_version.txt"
execute "ln -s #{release_path}/pub/static #{release_path}/pub/static/version`cat #{release_path}/pub/static/deployed_version.txt`"

Then we are just going to Frontools dir, install dependencies (via npn or yarn) and run necessary Gulp tasks inside.

I don't get the part with "dev" directory, b/c as long as you are just "composer install" on the beginning of deployment pipeline, Frontools configuration will be on place without any hacks.

---

We are thinking to move this process into CI/CD pipeline and push ready to use code as a single ZIP to target server, which should be probably better option, but also a bit more complicated (you need an working M2 instance to do all of the compilation steps).

[bassplayer7]

Part of the problem is there is a lot that still needs to be figured out with some this front end tech. As a result, there is no true correct way to do this. If it works, it's generally good. 

Given the popularity of NodeJS build tools, it can make them appealing as a one-stop source for stylesheet compilation and other tasks. However, like you mentioned, it provides a significant obstacle if you don't already have a deployment process in place that can facilitate NodeJS. Frontools is more complicated because of the reasons that you mentioned. However, given the benefits during development, it can be worth the trade off. We use Jenkins pipelines, so deployment wasn't an issue for compiling with Gulp.

One other option would be to build a PHP SCSS compiler. I don't think it will be super clear/easy to do but there is an example module that helps with a start: https://github.com/magento/magento2-samples/tree/master/module-sample-scss

Also, there could be a way around including part of the dev/ folder in production. The config files are just there for convenience. You could temporarily put a themes.json folder directly in `vendor/snowdog/frontools/config/` during a deployment process.

That said, I do hope the dev/ folder will be visited and perhaps, the config aspects of it moved to a `config` folder or something that has files per mode (dev, prod, etc).

[Bartek Igielski]

PHP SCSS based compilation isn't a replacement of things handled on Frontools level, i.e. b/c lack of PostCSS (like Autoprefixer) replacement in PHP.

I'm also pretty sure that any front-end developer will not work with any PHP based tools, even just b/c mostly we doesn't know PHP that good to feel comfortable with customizing them for own needs.

[bassplayer7]

Ah, yes. I had forgotten about Autoprefixer - which indeed wouldn't work with the PHP library.

I agree that PHP based tools aren't necessarily a perfect solution for a permanent measure within Magento 2 (hence the other discussion on this board regarding that). However, there are times when they can be a good option. 

[javiervd]

I agree, don't get me wrong I'm not saying PHP compilation is the best option, I think processing assets using NodeJS has too many advantages not to use it my question was geared more about how to handle this during deployments.

[javiervd]

This is very useful thanks.

To clarify my question about the dev folder was more about how to handle the "themes.json" file. Frontools uses this file to 'detect' your custom theme so it needs to be in either "dev/tools/frontools/config" or "vendor/snowdog/frontools/config" so because we ignore the vendor folder in our deployment it leaves us with a few options:

• Add the "theme.js" file to the "vendor/.." folder as part of the deployment process, so even though we ignore the vendor folder we can create the file on the fly after composer installs dependencies.
• Include the "dev/tools.." folder.
• Pass the "theme.js" settings as config options to the gulp release task in production which I think it's not supported atm.

Maybe I'm getting some parts of this wrong that's why I was curious too see how you guys handled it.

[Bartek Igielski]

We are creating new composer package per every project, just to keep Frontools configuration files.

In composer.json you can define an "map" option (will work only with M2). It's designed to copy files outside of packages, so is perfect for this type of job.

Sample config:

{
    "name": "snowdog/module-{project}-frontools",
    "description": "{project} Frontools configuration",
    "type": "magento2-component",
    "require": {
        "snowdog/frontools": "1.1.3"
    },
    "extra": {
        "map": [
            [
                "config",
                "dev/tools/frontools/config"
            ]
        ]
    }
}

[javiervd]

That's interesting I wasn't aware of the map option, thanks!