Migros Shared Components build tool
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.
- 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.
# Install dependencies
# Create build
npm run build
# Create build and watch for changes
npm run develop
Use the msc-cli to show available configuration options:
node ./bin/msc-cli -h
Usage: msc-cli [options] [command]
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.
-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
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
- 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?
- 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)
- Web interface for partial builds?