We are planning to start a new Helix principles compliant project.
We got pretty good idea on backend Sitecore solution setup by looking at Habitat implementation.
Keen to get your advice based on your Helix project on:
How to set up the front end assets (css/jss) that match with backend Helix setup e.g. feature with css/js ?
How does front end team integrate with backend ?
Thanks.
For Point 1 have a closer look at the Foundation projects "Sitecore.Foundation.Assets" and "Sitecore.Foundation.Theming" in the Habitat solution.
Sitecore.Foundation.Assets makes it possible to add assets by theme, page or rendering. The Theming project allows you to add different themes to a site.
Point 2 is very based on your organisational structure, front-end-team should work in .less files which are compiled to .css file by Web Compiler and Bundler & Minifier (both VS extensions).
Our front end team works separately in Pattern Lab, and we don't require them to have Sitecore running to do their work. It's just not efficient for them to have to learn Sitecore or manage a local Sitecore environment.
We typically take their compiled FE assets and put them at the Project level, this is done with a gulp task when we run a build/deploy. This way you can have some common base assets that are shared by all sites, then specific Project files for site specific overrides or themes. You can organize your FE assets by tenant/site according to the Helix principles this way, at the Project level.
Habitat advocates keeping FE assets alongside the features, and that's great for full stack teams, but it's not practical for our team's workflow.
The question might be a little too broad for StackExchange, since it invites discussion, but, what we do is as follows:
Our design team works within their own space, using Jekyll to generate a static site on pages and modules. While creating modules they determine the CSS/SASS (and JS/hopefully TypeScript one day) necessary for those individual modules to work.
They have a build process (currently Grunt) that compiles minified CSS and JS for the entire site (collection of almost all modules). Those assets are deployed to Azure as a versioned (/yyyy/mm.dd/...) release, and they let the dev team know.
We have a project layer module (Xxx.Project.Common, since our websites share the outer wrapper) that defines the main layout(s) and adds the base CSS/JS includes within those layouts.
We then have a Xxx.Feature.Yyy module for each individual component that the designers develop. We take advantage of the Sitecore.Foundation.Assets module from the Habitat project in cases where we want specific JS (and eventually CSS) to be included when the module is added to the page. These are tied to the module in Sitecore, with the path to the asset on Azure/CDN entered into the corresponding field in Sitecore.
This allows our designers to work with HTML, CSS, and JS, without having to get deep into the code itself. The modular approach they're taking also makes it easier to create these as Helix-based modules.
Another big benefit of starting with flat HTML components is that it makes it easier for these to be ported over to WordPress as well as static sites.
Check out the yeoman generator for Sitecore helix by Anastasiya Flynn. It gives a great scaffold for using TypeScript, Babel, Webpack, SCSS in a helix project.
