Page tree

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


  • Update Lens structure to facilitate file-type based theming and to be consistent with other repository structures
  • Version School of Management's theme, alongside Lens
  • Release the structural changes as Lens 105


  • SoM's theme in relation to Lens, whether it uses a live copy, a snapshot or nothing
  • Whether SoM's theme should be versioned with Lens, if at all
  • How we handle other themes that could exist in the future


As SoM and Lens are intrinsically connected, we should increment versions of Lens and SoM in tandem.

This will As both will be using the same version number and therefore the same variable, this will not affect the lens-config.json file.


We need a solution that is easy to scale and add to so that we futureare future-proofed for other themes. This means having a plan or guide on how to add new themes to Lens.


Structuring by organisational relationships would reduce the changes required to Lens to accommodate SoM. We would be able to add the new theme our current to our current structure and there would be less chance of breaking existing pages (although there is confusion around how themes related relate to files in the /universal directory). However, the organisational structure of the university is irrelevant to developers and would require knowledge of the organisation to navigate - this would be particularly difficult for new starters or sharing our code-base with external parties. Sticking to the organisational structure would make it more complex to scale in the future, and would require some work deciding where the project sits in the organisation which could have political or managerial implications.

Structuring by theme would require initial changes to multiple repositories, however this would simplify scaling up (or adding new themes) in the future, additions . Additions would be straight forward and require no extra decisions or politcal discussions. This is also the structure that we are using in other repositories affected by the SoM theming - an example of this is the erb_templates directory in cms-publisher where the files are separated by file-type and then by theme, it makes sense to maintain this consistency.



Logical - Everything is tidy and you know where to find specific filetypes

Scalable - Structures across themes are mirrored, and easily expandable

Reduces complexity and confusion

Work is required to change

  • Grunt (largely done)
  • Lens
  • Lens-design-system
  • CI pipelines - where to copy the Grunt generate generated files

Output URL structure