Tips for Developers

1. ESLint config for Visual Studio Code

If you want to fix ESlint errors in Visual Studio Code change User/Workspace settings, by editing settings.json file. Add:

"eslint.validate": [
    {  
        "language":"javascript",
        "autoFix":true
    },
    {  
        "language":"javascriptreact",
        "autoFix":true
    },
    {  
        "language":"typescript",
        "autoFix":true
    },
    {  
        "language":"typescriptreact",
        "autoFix":true
    }
]

Setup auto-fix linting problems shortcut

1. Go to keyboard bindings settings in VS Code.
2. Search for "ESLint: Fix all auto-fixable problems"
3. Click on found row, Keybinding column and set a desired keyboard shortcut (for example CTRL+SHIFT+I)
4. Press enter

Running on Windows Subsystem for Linux 2

Debian

Configure .env URLs

You need to get WSL instance IP address. Run this command:

bash.exe -c "ip addr | grep -Ee 'inet.*eth0'"

Grab first IP address and then, for example, before running:

TAG=canary ./origin-docker-run.sh

Change BACKEND_URL in .env file to be using that IP address you just got. For example if command output was:

inet 171.11.151.33/20 brd xxx.xx.xxx.xxx scope global eth0

Then BACKEND_URL should be:

171.11.151.33:3030

2. Debug UI tests in VS Code

Use breakpoints and take advantage of VS Code debugging experience.

1. Open Debug pane
2. Open launch.json by clicking settings icon in Debug pane (next to selected configuration)
3. Add following configuration:

{
    "type": "node",
    "name": "Debug Jest Tests",
    "request": "launch",
    "program": "${workspaceFolder}/node_modules/jest/bin/jest",
    "args": [
        "--runInBand"
    ],
    "cwd": "${workspaceFolder}/packages/origin-ui",
    "console": "integratedTerminal",
    "internalConsoleOptions": "neverOpen",
    "disableOptimisticBPs": true
}

4. Place breakpoints in UI code, for example, in tests
5. Select newly added configuration in Debug pane and press start

3. Move VSCode Terminal to the right

https://stackoverflow.com/a/53352975/2166409

4. SemVer versioning using lerna

This repository is using SemVer based versioning sourced from Conventional Commits.

Conventional Commits quick reference

This means the structure of the commits has to follow the scheme:

• fix(component): title + body with explanation -> use when fixing a bug, this will result with packages getting version bump on patch level for e.g 1.0.0 -> 1.0.1
• feat(component): title + body with explanation -> use when adding a feature, this will result with packages getting version bump on minor level for e.g 1.0.0 -> 1.1.0
• chore(component): title + body with explanation -> use when refactoring, this will not result with package getting version bump
• both fix and feat can contain "BREAKING CHANGE: explanation" in the body of the commit message (-m "title" -m "body") -> this will result with package getting version bump on major level for e.g 1.0.0 -> 2.0.0

Checking the future versions using lerna

lerna version --conventional-commits will print all version bumps according to commits since last release tag

Retrospective versioning

If for some reason you forgot to properly form your commits you can do that before the release but committing a change to a target package with proper commit message as mentioned above. An example can be found here

5. Travis build triggering

Our canary release pipeline depends on receiving consecutive TRAVIS_BUILD_NUMBER so it can attach it to npm canary versions:

"publish:canary": "lerna publish --yes --skip-git --exact --cd-version=prerelease --pre-dist-tag canary --preid=alpha.$TRAVIS_BUILD_NUMBER"

If for some reason you build failed and you wish to re-trigger, please use "More options -> Trigger build" functionality on Travis

6. Run test:ci:contracts when ports are taken

sudo kill -9 `sudo lsof -t -i:8546`; sudo kill -9 `sudo lsof -t -i:8547`; sudo kill -9 `sudo lsof -t -i:8548`; sudo kill -9 `sudo lsof -t -i:8549`; sudo kill -9 `sudo lsof -t -i:8550`; sudo kill -9 `sudo lsof -t -i:8551`; yarn test:ci:contracts