eXtended Office Add-ins project generator – Architecture

By | January 3, 2019

December and January was a busy month for me, I have been reading lot about Yeoman generator. There is not much documentation about Yeoman generator, and even if there is some documentation I feel it is far from clarity. I don’t want to offence the Yeoman folks, in fact they have done very great job. I read their source code in Yeoman GitHub repository here to understand how does it work, and to get some ideas directly from the source code.

The objectives

My objectives is to create Office-X , a Yeoman generator composes official Microsoft Office Add-ins generator and community generators to order to create unlimited types of Office add-ins project.

The second objectives is that either official generator or community generator must be isolated to each other. They can be independently patched, managed or upgraded without impacting each other.

Application architecture

Figure 1. Application architecture

Generator-Office-X is a composed Yeoman generator, in which Generator-Office-X:app is the main entry point of the generator. The application contains many sub-generators which contributors can add independently without impacting other sub-generators. For example the current sub-generators are:

  1. Generator-Office:app , the official Microsoft Office Add-ins project generator
  2. Generator-Office-X:starter. this common sub-generator to execute common activities/operation before contributor’s specific generator activities.
  3. Generator-Office-X:finisher, this is common sub-generator to execute common activities/operation after contributor’s specific generator activities.
  4. Generator-Office-X:vue , this is example of contributor’s specific generator – which will provide specific actions in this case, modifying official Microsoft Office Add-ins project generator to use VueJs framework. Contributor can create many sub-generators without creating tight couple dependencies with the main application.

Figure 1, shows application architecture and how it links with official generator-office. I wrote my understanding about official generator-office in other post here.

The tools

Yeoman composability

Composability is a way to combine smaller parts to make one large thing. Sor of like Voltron

https://yeoman.io/authoring/composability.html

Generator-Office-X will be the main composer for many different Yeoman generator. Since the intension is to extend Generator-Office, hence the Generator-Office will be the first and foremost important sub-generator of the application.

In-memory fs-editor (mem-fs-editor)

Yeoman context exposes mem-fs-editor a file edition helpers that works on top of mem-fs. The mem-fs is in-memory file structure used by Yeoman generator during template generation process.

Yeoman main generator can pass option to the sub-generator, however each sub-generator owns their own process. And since every sub-generator is an isolated process, we can not easily transfer information between sub-generator easily.

Fortunately, Yeoman uses in-memory file system backed up by mem-fs and in memory file edition backed up by mem-fs-editor. This application uses the in-memory file system to transfer/read information between sub-generator. We can see in-memory file system as communication channel between sub-generators.

Others

We will add other modules as long as it is relevant and help to the project. Since I don’t want to reinvent the wheel, any relevant tooling will be added as when as needed. The tools including xml to json parser, npm version checker etc.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.