Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/simplicity-js/framework
The Framework Repository for the Simplicity MVC Framework
https://github.com/simplicity-js/framework
expressjs mvc mvc-framework-for-javascript nodejs web web-application
Last synced: 4 months ago
JSON representation
The Framework Repository for the Simplicity MVC Framework
- Host: GitHub
- URL: https://github.com/simplicity-js/framework
- Owner: simplicity-js
- Created: 2024-05-19T21:48:17.000Z (9 months ago)
- Default Branch: 1.x
- Last Pushed: 2024-09-14T20:08:51.000Z (5 months ago)
- Last Synced: 2024-09-29T12:40:55.942Z (4 months ago)
- Topics: expressjs, mvc, mvc-framework-for-javascript, nodejs, web, web-application
- Language: JavaScript
- Homepage:
- Size: 506 KB
- Stars: 1
- Watchers: 1
- Forks: 0
- Open Issues: 2
-
Metadata Files:
- Readme: README.md
- Changelog: CHANGELOG.md
Awesome Lists containing this project
README
# Simplicity
The Framework Repository for the Simplicity MVC Framework.
## Development
### Automated testing
#### Testing all modules
- Run all tests: `npm test`.
- Run all tests with coverage report: `npm run test:coverage`.
#### Testing individual modules and methods
- Test a directory: `npm test -- --`.
Examples:
- `npm test -- --application`
- `npm test -- --component`
- Test a module: `npm test -- --`.
Example: `npm test -- --env`.
**Note:** To test the `config` module (as opposed to testing one of its methods),
use `npm test -- --config::*`. This is because `npm test -- --config`
results in npm thinking we are passing config info and returning error:
`Error: Not enough arguments following: config`
Using `config::*` enables us to achieve our desired functionality.
- Test a module's method: `npm test -- --`
Example: `npm test -- --config::get`.
- Test nested module method:
`npm test -- --.[::]` or
`npm test -- --[::]`
Examples:
- Test the router (*src/component/router/index.js* file) methods: `npm test -- --component.router`.
#### Example tests
```bash
npm test // Run all tests inside the src/ directory
npm test -- --factory.cache // Run all tests inside the src/factory/cache/ directory.
npm test -- --factory.cache.file-cache // Run only the tests within the file-cache.spec.js file
npm test -- --factory.cache.FileCache // Ditto
npm test -- --component.router // Test only the methods of the router module (src/component/router.js)
```
### Committing and Pushing changes
This project follows the [Conventional Commits Specification][commits] and uses [ESLint][eslint] for linting.
Before committing your changes, run `npm run lint:fix` to check and automatically fix linting errors.
If there are linting errors that cannot be automatically fixed,
they are highlighted, so that you can manually fix them.
To commit your changes, run `npm run commit`. This will:
- generate conventional commit messages using [commitizen][commitizen] and [cz-conventional-changelog][changelog]
- check to make sure there are no linting errors
- run the tests to make sure the changes do not break existing functionality
- check that the minimum code-coverage threshold is attained
- apply the commit
Once everything checks out and the commit is applied,
you can then push your changes by running `git push -u remote pr/your-branch-name`.
You can keep making and pushing updates to your pull request branch
until you feel ready to have your changes merged into the main project.
When you are ready to have your changes merged, you can then [open a pull request][pr].
## Style guides
### Git Commit Messages
- Use the present tense ("Add feature" not "Added feature").
- Use the imperative mood ("Move cursor to..." not "Moves cursor to...").
- Limit the first line (subject line) to 72 characters or less.
- Reference issues and pull requests liberally after the first line.
- Consider starting the commit message with an applicable emoji:
- :sparkles: `:sparkles:` when adding a new feature
- :art: `:art:` when improving the format/structure of the code
- :bookmark: `:bookmark:` when creating a version tag
- :racehorse: `:racehorse:` when improving performance
- :non-potable_water: `:non-potable_water:` when plugging memory leaks
- :memo: `:memo:` when writing docs
- :bulb: `:bulb:` when adding doc-comments to source code
- :package: `:package:` when making a change to `package.json`
- :penguin: `:penguin:` when fixing something on Linux
- :apple: `:apple:` when fixing something on macOS
- :checkered_flag: `:checkered_flag:` when fixing something on Windows
- :bug: `:bug:` when fixing a bug
- :ambulance: `:ambulance:` whem making a critical hot fix
- :hammer: `:hammer:` when refactoring code
- :wheelchair: `:wheelchair:` when making accessibility (a11y) changes
- :fire: `:fire:` when removing code or files
- :green_heart: `:green_heart:` when fixing the CI build
- :white_check_mark: `:white_check_mark:` when adding tests
- :heavy_check_mark: `:heavy_check_mark:` when making tests pass
- :lock: `:lock:` when dealing with security
- :arrow_up: `:arrow_up:` when upgrading dependencies
- :arrow_down: `:arrow_down:` when downgrading dependencies
- :shirt: `:shirt:` when removing linter warnings
- :zap: `:zap:` when making general updates
- :boom: `:boom:` when making breaking changes
- :ok_hand: `:ok_hand:` code-review: okay
- :hankey: `:hankey:` code-review: needs improvement