Use different module templates for feature and foundation projects when using add-helixmodule.ps1

By

The add-helixmodule.ps

In my first Sitecore Helix project I got introduced to a PowerShell script add-helixmodule.ps1
This script has a few commands that you can call from the console inside Visual Studio:
  • Add-Feature
  • Add-Foundation
  • Add-Project
This script saves us a lot of time creating new feature and foundation projects in Visual Studio. It creates a project inside Visual Studio based on a "template".
The creator of this PowerShell script is Marc Duiker, for more info you can read about it in his blog post here.

Why have two different templates

After creating several feature and foundation projects, I wanted to extend the template to have more references and files in the feature projects. I did not want to add all of these changes when creating foundation projects.

The solution

I solved this by creating two module template folders. One for Foundations and another for Features.
In the Feature module template I added references to the foundation projects and added the files I wanted to be created when calling the Add-Feature command.
In the Foundation module template I removed the files we usually don't need there, and tried to make it as slim as possible.

Changes needed to make the commands use correct template folders

In the JSON file we have the following line:
"moduleTemplatePath": "C:\\yyy\\xxx\\module-template",

I created two new paths in the configuration:
"moduleFoundationTemplatePath": "C:\\yyy\\xxx\\module-template-foundation",
"moduleFeatureTemplatePath": "C:\\yyy\\xxx\\module-template-feature",

Changes to add-helixmodule.ps:
I changed the script so it would pick up the correct template paths. When using Add-Feature we would be using the moduleFeatureTemplatePath. When using Add-Foundation we would be using the ModuleFoundationPath.


Additional notes

If you end up with files and references you don’t use you should not add them, the templates are there to help you create the files and references that you need instead of adding them manually.
We did update the feature template with more items during the development, introducing Glass Mapper and more.
We made minimal changes to the initial foundation template.
We could also introduce a third module template folder for the Add-Project.

Comments

Ole said…
Added changes needed to have a different node module folder to the Add-project command.
Remember to add moduleProjectTemplatePath to the add-helix-module-configuration.json file.
September 20, 2018 at 9:51 AM
Post a Comment

Popular posts from this blog

Step by step guide to add Glass Mapper to Helix solution

By
Image
How to add Glass Mapper to Sitecore Helix solution There are probably different ways to set this up in a Helix solution. I have done this setup in 4 of our projects, and it has become the "template" for our new Helix solutions. We create one foundation project, which has all the glass nuget packages installed, we also choose to add a glass base in the foundation layer. All new features will have access to this glass base interface through a project reference.  I have had a lot of discussions with my co workers on where to add common fields that would be used in several feature projects. If it should be in the Glass Mapper foundation project or in a new foundation project. On "small" projects we choose to add it in the Glass Mapper foundation project, on larger projects we created a separate foundation project to add these fields and their interfaces with Glass Mapper mapping. 1. Create the Visual studio project From the Package Manager Console run
Read more

Using interfaces with Glass Mapper

By
Image
In one of my previous blog post I wrote an example on how to add Glass Mapper to Helix . I will in this blog post provide some code examples on how to map different fields with Glass Mapper. I will also provide some examples on how you could benefit more from Glass Mapper by using interfaces instead of models. Why use interfaces instead of models Interfaces can be inherited multiple times, this works well with inherited templates in Sitecore. We create the common fields in the Helix Foundation layer, and use the mappings in multiple feature projects. The mapping is created in separate interfaces. The model(interface) that should use the fields only needs to inherit from these interfaces. For example a simple component with Title and Rich Text would only need to inherit from the GlassBase, Title and Rich Text interface IMyComponent   :   IGlassBase ,   ITitle ,   IRichText Inside Sitecore the MyComponent would need the Title and RichText field The view then has access
Read more

Adding dynamic image source for multi-site solutions with $site$ token and setting dynamic datasource location for components

By
Image
Months after finishing a project I have had clients saying: We need to make a copy of the site you created and put some other content on it Most clients need to put this new site into the same solution because of restrictions in their Sitecore license. To convert old projects there was usually a lot of content restructuring and code changes needed. I have done this exercise multiple times. I try to have this in mind when creating new solutions so we don`t end up with too much effort when adding support for multi sites at a later stage. Even with great structure and code we still face some problems. In a multi-site solution you want to reuse components, but the sites should not always share the data locations and image folders. Most sites have different editors, they should not see the components and images from the other sites, we then need to place content in different folders and set the appropriate security on those. I recently got a request to duplicate an existing site,
Read more