weddingspot-core-monorepo v0.0.0

ws-core-fe

This repository is a monorepo composed of various, formerly stand-alone, front-end repositories. The goal of this monorepo is to make development of fthe various weddingspot frontend packages easier/faster to develope. We use lerna to manage both external and internal dependences (dependencies between internal packages).

Quick start

1. clone this repo
2. install lerna globally: npm install -g lerna
3. run npm config set @cvent:registry http://nexus.core.cvent.org:8081/nexus/content/groups/npm-public/
4. npm login
5. new macos installs may need to also install some other deps:

# npm/nodejs deps
npm install -g node-gyp
brew install pkg-config cairo libpng jpeg giflib
npm install canvas

# Add npm credentials for @honeybook
npm adduser
<enter username>
<enter password>

1. Install and configure Prettier plugin (VS Code or WebStorm) to follow code style guides.
2. Configure enable Prettier auto-format on save

# VS Code
Open .vscode/settings.json on a root folder
If there is no such file simply create a new one
Add following section there:
{
    "files.autoSave": "onFocusChange",
    "editor.formatOnSave": true,
    "editor.defaultFormatter": "esbenp.prettier-vscode",
}

# WebStorm
Open Preferences → Languages & Frameworks → JavaScript → Prettier and enable the option Run on save for files.

There are two different packages that can serve code at the moment:

• weddingspot-core-react
• ws-next

1. install all package dependencies and symlink internal dependencies: lerna bootstrap
2. build dependent packages

cd packages/ws-api-client && npm run build
cd packages/ws-api-analytics && npm run build
cd packages/ws-core-components && npm run build

3. run weddingspot-core-react: cd packages/weddingspot-core-react && npm run start
4. run ws-next: cd packages/ws-next && npm run dev

Dev flow

Typical scenario: you want to add a new feature to the site, the feature requires a new api endpoint that needs a client implementation in ws-api-client before being used by ws-core.

If you want to consume changes in weddingspot-core-react

1. Run npm run start from weddingspot-core-react package
2. Make changes to ws-api-client
3. Done. Your build should succeed and your latest changes to the ws-api-client package should be available immediately

If you want to consume changes in ws-next

1. Run npm run dev from ws-next package
2. Make changes to ws-api-client
3. Run npm run build from ws-api-client package
4. Done. Your build should succeed and your latest changes to the ws-api-client package should be available immediately

Caveats:

• You should not use npm install in any of the subpackages, use lerna boostrap instead to properly manage dependencies
• Depending on your IDE, your syntax-highlighting linter might not immediately detect changes to local dependencies (only for next now)

Adding a new package

The prodedure is largely the same as you would typically create a new npm package:

1. create new dir in packages/ dir: mkdir packages/my-cool-pkg
2. initialize the dir as an npm package roo: npm init
3. add the package as a dependency to other local packages that need it e.g.: lerna add my-cool-pkg --scope=ws-core

Versioning

To ensure versioning best practices, please follow semver versioning practices. Quick overview for the lazy, the semver format is as follows:

X.Y.Z[-P.R]

X - Major version; increment this for non-backwards compatible changes Y - Minor version; increment this for backwards compatible additions (e.g. new features/types/interfaces) Z - Patch version; increment this for changes that don't modify the exported interfaces (e.g. bugfixes) P - Prerelease identifier; this value can be any string, we use the following convention: "staging" for staging-only releases; "dev" for other releases R - Prerelease number; this is a number, increment this for each subsequent prerelease

Example Scenario Let's say the current prod version is 1.2.3 and you want to publish some bugfixes for staging.

The next version would be: 1.2.4-staging.0 Next staging versions would be: 1.2.4-staging.1 Once the package is ready for prod release: 1.2.4

Releases

There are 2 npm scripts associated with the repo root called release and forceRelease. When you're ready to publish your changes:

1. run npm run release
2. The script will first prompt you to specify new versions for each package. Use the versioning guide in the "Versioning" section above, this will be verified by the release script. You will not be allowed to publish versions that are labeled incorrectly.
3. The script will then run through version validation, run any unit tests, and build the package based on the current branch (build for master, buildStaging for staging)
4. Finally the script will attempt to publish all packages that were successfully versioned

If you need to promote a prerelease version for production without making any changes, you'll need to do the following:

1. run git commit --allow-empty -m "Promote to prod release version" (this creates an empty git commit w/ a message)
2. run npm run forceRelease (this will run through all the same steps as the release script, except force publish packages with no git diffs)

If you have a special release case that isn't covered by the scripts above you can still build/release manually, but please make sure you know what you're doing...

NOTE: this step is automated in Jenkins (see RELEASE_FE_PACKAGES flag).

Example Scenario Let's say the current prod version is 1.2.3, you've implemented a new feature in your branch my-feature-branch and you want to deploy to staging.

1. Merge your changes to the staging branch: git checkout staging && git merge my-feature-branch
2. Release staging build: npm run release (publish new version 1.3.0-staging.0)
3. Deploy to staging

Once your feature has been QA'd and PR approved you can release to prod

1. Merge your changes to master branch: git checkout master && git merge my-feature-branch
2. Release master build: npm run release (publish new version 1.3.0)
3. Deploy to prod

Docker commands

Build: docker build -t ws-fe . docker run --name ws -p 3000:3000 -e CHOKIDAR_USEPOLLING=true / -v pwd/packages/weddingspot-core-react/src/:/app/packages/weddingspot-core-react/src/ ws-fe npm start (-v using for sync local files and files in volume so in our case it sync only weddingspot-core-react folder ) if you need work with ws-core-components add -v pwd/packages/ws-core-components/src/:/app/packages/ws-core-components/src/ after that run in new terminal docker exec -it CONTAINER_ID bash go to ws-core-components and npm run buildLocal .npmrc also might be needed to be added for correct work

Will be helpfull for windows users: 1) Start Dockert as administrator 2) Share or reshare disk in docker with code. Can help: link 3) Check is docker not blocked by firewall or antivirus 4) Run example fo windows docker run --name wss -p 3000:3000 -e CHOKIDAR_USEPOLLING=true -v D:\wedding-spot\frontend\packages\weddingspot-core-react\src\:/app/packages/weddingspot-core-react/src/ -v D:\wedding-spot\frontend\packages\ws-core-components\src\:/app/packages/ws-core-components/src/ -v D:\wedding-spot\frontend\packages\ws-analytics\:/app/packages/ws-analytics/ ws-fe npm start

Shared dependencies & integration testing

The beauty of using lerna is the ability to specify shared dependencies across all packages and the ability to define multi-package integration test.

Take a look @ this article on how to set up a basic integration test in a lerna-managed repo (no magic).

TODO: add a real example test to the repo