├── .github ├── CODE_OF_CONDUCT.md ├── CONTRIBUTING.md ├── ISSUE_TEMPLATE │ ├── bug_report.md │ └── feature_request.md ├── PULL_REQUEST_TEMPLATE.md ├── commit-convention.md ├── funding.yml ├── settings.yml └── workflows │ ├── release-tag.yml │ ├── size-limit.yml │ └── test.yml ├── .gitignore ├── .prettierrc.js ├── .vscode └── settings.json ├── LICENSE ├── README.md ├── __tests__ └── index.spec.ts ├── api-extractor.json ├── jest.config.js ├── package.json ├── renovate.json ├── rollup.config.js ├── scripts ├── release.sh └── verifyCommit.js ├── size-checks └── basic.js ├── src ├── global.d.ts └── index.ts ├── tsconfig.json └── yarn.lock /.github/CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | # Contributor Code of Conduct 2 | 3 | As contributors and maintainers of this project, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities. 4 | 5 | We are committed to making participation in this project a harassment-free experience for everyone, regardless of level of experience, gender, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, age, or religion. 6 | 7 | Examples of unacceptable behavior by participants include the use of sexual language or imagery, derogatory comments or personal attacks, trolling, public or private harassment, insults, or other unprofessional conduct. 8 | 9 | Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct. Project maintainers who do not follow the Code of Conduct may be removed from the project team. 10 | 11 | Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by opening an issue or contacting one or more of the project maintainers. 12 | 13 | This Code of Conduct is adapted from the [Contributor Covenant](http://contributor-covenant.org), version 1.0.0, available at [http://contributor-covenant.org/version/1/0/0/](http://contributor-covenant.org/version/1/0/0/) 14 | -------------------------------------------------------------------------------- /.github/CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Contributing 2 | 3 | Contributions are welcome and will be fully credited! 4 | 5 | We accept contributions via Pull Requests on [Github](https://github.com/{{ githubAccount }}/{{ name }}). 6 | 7 | ## Pull Requests 8 | 9 | Here are some guidelines to make the process smoother: 10 | 11 | - **Add a test** - New features and bugfixes need tests. If you find it difficult to test, please tell us in the pull request and we will try to help you! 12 | - **Document any change in behaviour** - Make sure the `README.md` and any other relevant documentation are kept up-to-date. 13 | - **Run `npm test` locally** - This will allow you to go faster 14 | - **One pull request per feature** - If you want to do more than one thing, send multiple pull requests. 15 | - **Send coherent history** - Make sure your commits message means something 16 | - **Consider our release cycle** - We try to follow [SemVer v2.0.0](http://semver.org/). Randomly breaking public APIs is not an option. 17 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/bug_report.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Bug report 3 | about: Create a report to help us improve 4 | title: '' 5 | labels: '' 6 | assignees: '' 7 | --- 8 | 9 | ### Reproduction 10 | 11 | If possible, provide a boiled down editable reproduction using a service like JSFiddle, Codepen or CodeSandbox. A failing unit test is even better! Otherwise provide as much information as possible to reproduce the problem. 12 | If no reproduction is provided and the information is not enough to reproduce the problem, we won't be able to give it a look 13 | 14 | ### Steps to reproduce the behavior 15 | 16 | 1. Go to '...' 17 | 2. Click on '....' 18 | 3. Scroll down to '....' 19 | 4. See error 20 | 21 | ### Expected behavior 22 | 23 | A clear and concise description of what you expected to happen. 24 | 25 | ### Actual behavior 26 | 27 | A clear and concise description of what actually happens. 28 | 29 | ### Additional information 30 | 31 | Add any other context about the problem here. 32 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/feature_request.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Feature request 3 | about: Suggest an idea for this project 4 | title: '' 5 | labels: feature request 6 | assignees: '' 7 | 8 | --- 9 | 10 | ### What problem is this solving 11 | 12 | A clear and concise description of what the problem is. Ex. when using the function X we cannot do Y. 13 | 14 | ### Proposed solution 15 | 16 | A clear and concise description of what you want to happen with an API proposal when applicable 17 | 18 | ### Describe alternatives you've considered 19 | 20 | A clear and concise description of any alternative solutions or features you've considered. 21 | -------------------------------------------------------------------------------- /.github/PULL_REQUEST_TEMPLATE.md: -------------------------------------------------------------------------------- 1 | 5 | 6 | 7 | 8 | 9 | 10 | **What kind of change does this PR introduce?** (check at least one) 11 | 12 | - [ ] Bugfix 13 | - [ ] Feature 14 | - [ ] Code style update 15 | - [ ] Refactor 16 | - [ ] Build-related changes 17 | - [ ] Other, please describe: 18 | 19 | **Does this PR introduce a breaking change?** (check one) 20 | 21 | - [ ] Yes 22 | - [ ] No 23 | 24 | If yes, please describe the impact and migration path for existing applications: 25 | 26 | **The PR fulfills these requirements:** 27 | 28 | - [ ] When resolving a specific issue, it's referenced in the PR's title (e.g. `fix #xxx[,#xxx]`, where "xxx" is the issue number) 29 | - [ ] All tests are passing 30 | - [ ] New/updated tests are included 31 | 32 | If adding a **new feature**, the PR's description includes: 33 | 34 | - [ ] A convincing reason for adding this feature (to avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it) 35 | 36 | **Other information:** 37 | -------------------------------------------------------------------------------- /.github/commit-convention.md: -------------------------------------------------------------------------------- 1 | ## Git Commit Message Convention 2 | 3 | > This is adapted from [Angular's commit convention](https://github.com/conventional-changelog/conventional-changelog/tree/master/packages/conventional-changelog-angular). 4 | 5 | #### TL;DR: 6 | 7 | Messages must be matched by the following regex: 8 | 9 | ```text 10 | /^(revert: )?(feat|fix|docs|dx|style|refactor|perf|test|workflow|build|ci|chore|types|wip)(\(.+\))?: .{1,50}/ 11 | ``` 12 | 13 | #### Examples 14 | 15 | Appears under "Features" header, `link` subheader: 16 | 17 | ``` 18 | feat(link): add `force` option 19 | ``` 20 | 21 | Appears under "Bug Fixes" header, `view` subheader, with a link to issue #28: 22 | 23 | ``` 24 | fix(view): handle keep-alive with aborted navigations 25 | 26 | close #28 27 | ``` 28 | 29 | Appears under "Performance Improvements" header, and under "Breaking Changes" with the breaking change explanation: 30 | 31 | ``` 32 | perf: improve guard extraction 33 | 34 | BREAKING CHANGE: The 'beforeRouteEnter' option has been removed. 35 | ``` 36 | 37 | The following commit and commit `667ecc1` do not appear in the changelog if they are under the same release. If not, the revert commit appears under the "Reverts" header. 38 | 39 | ``` 40 | revert: feat(compiler): add 'comments' option 41 | 42 | This reverts commit 667ecc1654a317a13331b17617d973392f415f02. 43 | ``` 44 | 45 | ### Full Message Format 46 | 47 | A commit message consists of a **header**, **body** and **footer**. The header has a **type**, **scope** and **subject**: 48 | 49 | ``` 50 | (): 51 | 52 | 53 | 54 |