Skip to content

Latest commit

 

History

History
82 lines (54 loc) · 4.83 KB

README.md

File metadata and controls

82 lines (54 loc) · 4.83 KB
Raw

Build Status Release Status License: CC BY-NC-SA 4.0

Digital Pāli Reader

Current backlog is maintained here.

The Digital Pāli Reader is a tool much like a hard-copy language reader. The tool includes the Pāli canon and related scriptures. It includes multiple dictionaries to facilitate reading the scriptures. In addition to enabling an immersive experience for the study of the Tipitaka, it is also useful in the study of the Pāli language at an advanced level. The Digital Pāli Reader is used by Buddhist monks in their Pāli studies, at Universities around the world and by lay users for study at home.

Build and test instructions

Run DPR on the local machine:

  1. Install dependencies: yarn
  2. Run "start" script in root folder: yarn start
  3. Browse to http://localhost:8085

Run tests:

yarn test

Lint:

yarn lint

Build service worker:

yarn build:sw

Modern HTML5/CSS3/ES6

webpack & friends

Working effectively with legacy code

The current codebase has organically evolved since the last decade. Every piece of code implements some critical functionality.

For the following reasons working with the code base is tricky:

  • Lots of students, professors, monastics depend on DPR for their day to day work.
  • Code and markup aren't cleanly separated, special care must be taken to not break stuff when changing the code.
  • Manual testing process are not yet streamlined.

Over a period of time with care and above infrastructure support (linters, prettiers, testing processes), the code base will evolve to be much easier to change.

Here is an excellent book for techniques for working effectively with legacy code.

Guidelines for contributions

This is a 'live' section. Feel free to suggest amendments through PRs.

  1. DO reuse existing code. Remember that features that are being ported over from XUL to Web are already working.
  2. DO make only the minimum changes necessary for implementing features, fixing bugs. VSCode will auto format those changes as per .editorconfig and other settings.
  3. DO abstract out HTML ids behind PAL interface. E.g. DPR_PAL.getDifId();
  4. DO ask for buddy testing.
  5. DO test all scenarios (TBD: Link to manual test scenarios that every commit must pass)
  6. DO resolve all PR comments through discussion.
  7. DO follow the project conventions for all new code: ES6, jQuery, HTML5, CSS3, Bootstrap.
  8. DON'T bulk format files. This makes it very hard to trace the exact changes in case a revert is required.
  9. DON'T do non-trivial refactoring. It becomes hard to track changes across commit and revert selectively when necessary.
  10. DON'T change HTML class names or ids. It is hard to tell which is being directly referenced form the code.

Upcoming Infrastructure support to make codebase easy to change

  • Linters.
  • Unit tests.
  • Effective manual testing process.

Useful links