npm

Check out our latest tech talk, "JavaScript Supply Chain Security" presented by VP of Security, Adam Baldwin.Watch it here »

@axa-ch/midgard

1.3.1-alpha.2 • Public • Published

Midgard

This will generate clientlibs for AXA.ch from different PODs

Prerequisites

Recommendations

Every script based solution works much better on UNIX Systems, therefore we highly suggest to enable the UNIX Subsystem on Windows for the correct execution. Even if we try to make it as much Windows compatible as possible, node executables relays a lot on the bash shell and therefore any Windows emulation could lead to unexpected results. We will only test this solution on Windows 10 having the UNIX Subsystem active.

Automated POD initialiser

Please checkout the Create Pod APP on how to setup your POD: https://github.com/axa-ch/create-pod-app#create-pod-app You can also have a look at a skeleton POD (created automatically with the create-pod-app): https://github.com/axa-ch/pod-skeleton-example

Configurations

The config.json is the brain of everything. There is stored which library is required and on which version. Versioning format and option are the same as on NPM.

We expect every ES Module (POD) to contain this structure: lib/index.js. Index JS is where everything is loaded. CSS, SCSS and all components have to be included here. If for some reason the init files is called differently, you can set { entry-file": "aletheia.es" } as an entry file. Now the expected path will be lib/aletheia.es.

Lets see now in detail all the configurations:

{
  // is the location on where all the pods will be created and bundled
  "rootPathClientlibs": "./.tmp/aem",
  // a list of all installed pods. This will be used if no specific POD is passed when
  // calling midgard (npm run midgard)
  "installedPods": [
    // NPM NAME aletheia with NPM version latest. Bootstrap type is STORE & oAUTH (features of bifrost). Entry file as described above
    { "aletheia" : "latest", "type": "store-auth", "entry-file": "aletheia.es" },
    { "axa-ch-core" : "beta", "type": "basic" }
  ]
}

Lets have a deeper dive into all the types:

  • Type: "store-auth" -> enables the bifrost store and passes a oauth token to the POD. Requires a default class export. Passes the element and all the attributes data as object
  • Type: "auth" -> just passes a token on bootstrap. Requires a default class export. Passes the element and all the attributes data as object
  • Type: "store" -> just passes a store reference. Requires a default class export. Passes the element and all the attributes data as object
  • Type: "on-dom-loaded" -> Will instantiate the POD when DOM is ready. Passes the element and all the attributes data as object
  • Type: "basic" -> this will just include the Javascript. Everything is handled in the POD (Expert only).

Use guide - create your clientlib for AEM

Here are described the most important features and commands on how to use Midgard.

Pre-assumption: You need to have your POD already configured and ready as described here: https://portal.paas.intraxa/confluence/display/DXS/How+to+best+prepare+your+POD

Common chunks

Midgard can build all configured pods with theier version (example).

When Midgard is called without any parameters (Bundle ALL), it will build all pods and prepare the clientlibs. Aditionally it will extrapolate all common NPM libraries using the following logic: if direct dependent npm module of POD or sub-npm module of POD is in > 1 PODs, then add it to common.js. The POD js is loaded only on the AEM page where the PODs HTML is present. Common.js instead is loaded everywhere and is cached via Browser Cache. This is done to improve the overall usability of the website due to reduced bundle size and optimal chaching. It also has small benefit for google SEO ranking.

When Midgard is called with a parameters (Bundle ONE), then ONLY the POD specifified in the parameter will be created. If a version is passed, it will use the specified version INSTEAD of the one defined in the manifest.json. Example: npm run midgard -- -name="aletheia" -version="1.0.0". This special build is needed during incremental build triggered from each product team via the jenkins webhub pipelines. When midgard runs in this mode, no common chunks logic is applied. Reason: so that every developer can indipendently test theier POD and are not bound to other PODs, common chunks here is ignored. The downside of this is that bundle size gets bigger for each pod. Most of the times, however, this downside only affects PODs on DEV or ACC as those environments are responsible for heavier testing and therefore heavier incremental build need.

Use guide - Test your WebPack Build

We created a "primitive" dev environment to test the bundling of the clientlibs.

Use npm run dev for creating a index.html file that loads all the clientlibs contained inside .tmp/aem-js. It will do an update so therefore is usefull for testing single module rebuilds

Use npm run dev-clean cleans the workspace before copying from .tmp/aem-js. Therefore you will have a fresh install from the installed pods.

Keywords

none

install

npm i @axa-ch/midgard

Downloadsweekly downloads

59

version

1.3.1-alpha.2

license

SEE LICENSE IN README.md

homepage

github.com

repository

Gitgithub

last publish

collaborators

  • avatar
  • avatar
  • avatar
  • avatar
  • avatar
  • avatar
  • avatar
  • avatar
  • avatar
  • avatar
  • avatar
  • avatar
  • avatar
  • avatar
  • avatar
  • avatar
  • avatar
  • avatar
  • avatar
  • avatar
  • avatar
  • avatar
Report a vulnerability