node package manager

msc-build

Migros Shared Components build tool

Introduction

TODO: What are the modularized shared components? Why? How?

The modularized components consist of mainly four repositories as follows:

The full documentation of all available components and widgets can be found on msc-documentation.prod-migros.ch. CDN Uploads and Documentation are generated by the ch.migros.msc-documentation repository.

Goals

  • Minimize development efforts: Components can be developed isolated from other components while still relying on them
  • Smaller files, less ressources: Sites which don't need all of the components should be able to only load the needed components and its dependencies
  • Individual versioning and releases: Each site should be able to choose their own version of the different components. A site should be able to be updated with the latest component changes while another site wont.

Links

Usage

# Install dependencies
npm install
 
# Create build
npm run build
 
# Create build and watch for changes
npm run develop

Configuration

Use the msc-cli to show available configuration options:

node ./bin/msc-cli -h
 
  Usage: msc-cli [options] [command]
 
 
  Commands:
 
    develop [options]                          Runs the components in developer mode.
    test [options] [testFiles...]              Runs tests for the actual package, optionally test files can be specified to run.
    build [options] <entryFile> [buildFolder]  Builds the shared components with the given entryfile. This is ment for production build or developing an integrated site.
 
  This CLI manages building / developing / testing for the migros shared components.
 
  Options:
 
    -h, --help     output usage information
    -V, --version  output the version number

Create a new Modularized Component

Use the yeoman generator to create the skeletton of a new modularized component.

Create a customized build of components

TODO: Howto create a custom entrypoint and let it build for e.g. jobs.migros.ch with only jobs widget + base modules

TODOs

  • Build optional deps as separate packages, e.g. moment.js
  • Combine each of the components changelog into the documentation page
  • Documentation & Readme for Modularized Shared Components
  • Add & discuss Guidelines / Best Practices
  • Make sure that all legacy images are copied during build to /img (other assets probably too)
  • Exclude jQuery in Build as its already provided by the implementing page
  • Setup Build and Deployment to CDN (as before to get a smooth switch to the new setup)
  • Setup Build and Deployment to https://components.migros.ch/ and https://test-components.migros.ch/ -> see msc-documentation.prod-migros.ch
  • Move all legacy code to msc-legacy
  • Completely isolate one or two modules
  • Include all deps that were previously fetched with bower (check bower.json)
  • Run tests (see below)
  • Add linting
  • Custom Translations
  • Custom Stylesheets
  • Documentation pages without assemble.io
  • Eventually move static assets (fonts, images) to CDN
  • Eventually replace current JS widget API documentation snipped generator with something like markdox

Assets (images, fonts, ..)

  • Images that barely change such as logos should be moved to an image service such as image.migros.ch
  • Fonts should be placed in a central place such as the Migros CDN

Releases

  • Should get overhauled and be much faster in general
  • Use something like semantic-release?
  • Lock down deps using shrinkwrap or similar for each release?
  • How to handle CHANGELOG.md? Each module has its own and msc-build generates a single one out of it
  • Ditch RELEASE.md?

Overall Release

  • One release that contains all available MSC packages
  • Available on Migros CDN
  • Built manually or automatically once a MSC package releases a new version? Release cycles?
  • Versioning: Semver (not really possible without a lot of manual testing) or Date Of Release Versioning
  • New Migros CDN namespace? (if we change versioning to something like date of release syntax we should switch to a new namespace)

Future Outlook

  • Web interface for partial builds?