Skip to content

Latest commit

 

History

History
92 lines (61 loc) · 5.01 KB

developer_guide.md

File metadata and controls

92 lines (61 loc) · 5.01 KB

Developer Guide

Environment

Follow the installation instructions in the section Install standalone application directly from the source.

Install the javascript development requirements:

# in ~/<your-path-to-cloned-repo>/amundsenfrontendlibrary/amundsen_application
$ cd static
$ npm install --only=dev

To test local changes to the javascript static files:

# in ~/<your-path-to-cloned-repo>/amundsenfrontendlibrary/amundsen_application
$ cd static
$ npm run dev-build # builds the development bundle

To test local changes to the python files, re-run the wsgi:

# in ~/<your-path-to-cloned-repo>/amundsenfrontendlibrary/amundsen_application
$ python3 wsgi.py

Contributing

We describe our general contributing process in the main repository of Amundsen, so here we'll cover the items specific to the Frontend library.

Testing Python Code

If changes were made to any python files, run the python unit tests, linter, and type checker. Unit tests are run with py.test. They are located in tests/unit. Type checks are run with mypy. Linting is flake8. There are friendly make targets for each of these tests:

# after setting up the environment
make test  # unit tests in Python 3
make lint  # flake8
make mypy  # type checks

Fix all errors before submitting a PR.

Testing Frontend Code

npm run test runs our Frontend unit tests. Please add unit tests to cover new code additions and fix any test failures before submitting a PR. You can also have a dedicated terminal running npm run test:watch while developing, which would continuously run tests over your modified files.

To run specific tests, run npm run test-nocov -t <regex>, where <regex> is any pattern that matches the names of the test blocks that you want to run. See our recommendations for writing unit tests.

Frontend Type Checking

We use TypeScript in our codebase, so npm run tsc conducts type checking. The build commands npm run build and npm run dev-build also conduct type checking, but are slower because they also build the source code. Run any of these commands and fix all failed checks before submitting a PR.

Frontend Linting and Formatting

We have in place two linters – ESLint for our JavaScript and TypeScript files, Stylelint for our Sass files. If you have both ESLint and Stylelint extensions installed on your IDE, you should get warnings on your editor by default.

We also use Prettier to help us keep consistent formatting on our TypeScript and Sass code.

Whenever you want to run these tasks manually, you can execute:

  • npm run lint to run ESLint and npm run lint-fix to auto-fix most of them.
  • npm run stylelint to run Stylelint and npm run stylelint-fix to trigger the auto-fix.
  • npm run format to run Prettier on both the TypeScript and Sass files

We also check your changed files and format them when you create a new commit, making it easy for you and for the project to keep a consistent code style. We do this leveraging Husky and Lint-staged.

Looking forward, we aim at setting more strict best practices using ESLint and Stylelint. You can read about our plans to improve our TypeScript, Styles and general code style on these issues:

Accessibility and Semantic Markup

We strive to keep our application accessible. For that, we use the 'airbnb-typescript' preset for ESLint, which includes a bunch of accessibility rules. We also have a set of "jsx-a11y/" prefixed rules, which are currently on a "warn" level, so they don't throw errors. Our goal is to remove that "warn" level and comply with all the accessibility rules we list on our ESLint configuration.

We also try to model our application's markup on best practices regarding semantic markup. If you are making large markup changes on one of your PRs, make sure your changes comply with this HTML semantics checklist.