-
Notifications
You must be signed in to change notification settings - Fork 58
Tips for Developers
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
}
]
- Go to keyboard bindings settings in VS Code.
- Search for "ESLint: Fix all auto-fixable problems"
- Click on found row,
Keybinding
column and set a desired keyboard shortcut (for example CTRL+SHIFT+I) - Press enter
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
Use breakpoints and take advantage of VS Code debugging experience.
- Open Debug pane
- Open launch.json by clicking settings icon in Debug pane (next to selected configuration)
- 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
}
- Place breakpoints in UI code, for example, in tests
- Select newly added configuration in Debug pane and press start
https://stackoverflow.com/a/53352975/2166409
This repository is using SemVer based versioning sourced from Conventional Commits.
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
lerna version --conventional-commits
will print all version bumps according to commits since last release tag
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
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
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