The Franklin based project for business.adobe.com. Based off of milo-college.
Please carefully review the contributing doc before beginning development. Understanding the requirements will help facilitate a smooth contribution process.
- Install the Helix CLI:
sudo npm install -g @adobe/helix-cli
- Run
hlx up
this repo's folder. (opens your browser athttps://localhost:3000
) - Open this repo's folder in your favorite editor and start coding.
- After pulling the main branch, make sure to run
npm install
to get the husky pre-commit package. - Husky will run the linter and the test suite before your commit, and will not accept the commit if the either tool has errors or test failures.
- To bypass this, add the
--no-verify
flag after your commit message:
git commit -m "First" --no-verify
- Run 'hlx up' in this folder to ensure the bacom site is running locally.
- Make changes in milo, and then from the milo folder, run
npm run libs
. - Milo will run at:
https://localhost:6456
- On your
localhost:3000/
or themain-<project>-<owner>
versions of your site, add the URL params:?milolibs=local
- You should see milo changes occuring on bacom pages.
- When needing to test on a bacom page while making a PR for milo, add the URL params:
?milolibs=<name-of-milo-branch>
to your test URLs.
When creating new blocks, first vet any requirements/author-experience in milo-community. There may be a way to acheive your goals with what currently exists in milo.
npm run test
or:
npm run test:watch
This will give you several options to debug tests. Note: coverage may not be accurate.
To run the linter run:
npm run lint
To lint just js or css files, run
npm run lint:css
or:
npm run lint:js
If you need to lint just one file, you can run:
npx eslint file1.js
When logging do not use console
but instead use window.lana.log
, these logs will then be visible in Splunk.
Use tags to help filter logs. Tags should have the severity, see below, and the module/block name.
Tags should provide context, categorization, or help in filtering, etc.
Severity:
info = network issues or extra details to identify important information.
warn = authoring related mis-configurations or similar - this could lead to generating tickets.
error = actual error ( ex. cannot read Y of undefined ) - this could lead to generating tickets / CSOs depending on context.
Work with OPS to generate automatic tickets / CSOs, for example if an error causes the page or block not to render.
Example Logging:
window.lana.log('message', 'info, block-name');
More info: https://wiki.corp.adobe.com/display/WCMSOps/Best+Practices