feat(b-calendar/b-form-datepicker): add day, month, and year type options (closes #6034)

[christianklemp]

Describe the PR

This pull request adds types to the b-calendar and b-form-datepicker components to support for multiple types of date-related picking inputs. The types include date (default, and the current date picker), day (days of the week), month (months of the year), and year (years in a decade). I chose to have the components to keep the value formatting the same no matter what type is selected for consistency. Each instance can then utilize the date as needed and ignore the day, month, or year that aren't relevant for them.

I am working on a project where the month and year picker options will be needed in the near future, so I figured I'd add them for anyone else needing these options. Since the only issue that was open and seemed related didn't appear to be being worked on, I figured I'd jump in and get it done. Our development team has gone all-in on using BootstrapVue and we're wanting to avoid having another dependency just for a month and year picker.

I included days of the week since I was trying to generalize it for multiple use cases and am open to feedback. Tests have been added to cover these new types for both components. The documentation has been updated to include new props and updated wording for existing props that are related to types. Examples have been added for the b-calendar and b-form-datepicker README.md files for the documentation site to show users what the different type option experiences are like.

What it looks like

State	Date	Day	Month	Year
Initial
Open
Open with selection

Docs

b-calendar

b-form-datepicker

PR checklist

What kind of change does this PR introduce? (check at least one)

• [ ] Bugfix (fixes a boo-boo in the code) - fix(...), requires a patch version update
• [ ] Feature (adds a new feature to BootstrapVue) - feat(...), requires a minor version update
• [x] Enhancement (augments an existing feature) - feat(...), requires a minor version update
• [ ] ARIA accessibility (fixes or improves ARIA accessibility) - fix(...), requires a patch or minor version update
• [ ] Documentation update (improves documentation or typo fixes) - chore(docs), requires a patch version update
• [ ] Other (please describe)

Does this PR introduce a breaking change? (check one)

• [x] No
• [ ] Yes (please describe since breaking changes require a minor version update)

The PR fulfills these requirements:

• [x] It's submitted to the dev branch, not the master branch
• [x] When resolving a specific issue, it's referenced in the PR's title (i.e. [...] (fixes #xxx[,#xxx]), where "xxx" is the issue number)
• [x] It should address only one issue or feature. If adding multiple features or fixing a bug and adding a new feature, break them into separate PRs if at all possible.
• [x] The title should follow the Conventional Commits naming convention (i.e. fix(alert): not alerting during SSR render, docs(badge): update pill examples, chore(docs): fix typo in README, etc.). This is very important, as the CHANGELOG is generated from these messages, and determines the next version type (patch or minor).

If new features/enhancement/fixes are added or changed:

• [x] Includes documentation updates
• [x] Includes component package.json meta section updates (prop, slot and event changes/updates)
• [ ] Includes any needed TypeScript declaration file updates
• [x] New/updated tests are included and passing (required for new features and enhancements)
• [x] Existing test suites are passing
• [ ] CodeCov for patch has met target (all changes/updates have been tested)
• [x] The changes have not impacted the functionality of other components or directives
• [x] ARIA Accessibility has been taken into consideration (Does it affect screen reader users or keyboard only users? Clickable items should be in the tab index, etc.)

If adding a new feature, or changing the functionality of an existing feature, the PR's description above includes:

• [x] 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)

[vercel[bot]]

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/bootstrap-vue/bootstrap-vue/FEnq7X5CBhPVavpULYnVrizK9mzW
✅ Preview: https://bootstrap-vue-git-fork-christianklemp-date-d8c445-bootstrap-vue.vercel.app

[codesandbox-ci[bot]]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 8a477e8b8c192fde0c94f072d32f0dfed0a0f8bd:

Sandbox	Source
BootstrapVue Starter Project	Configuration
BootstrapVue Nuxt.js Starter Project	Configuration

[christianklemp]

@Hiws or @jacobmllr95 any idea why Codacy results are conflicting with what the prettify script updates for formatting? I have tried to update what it calls out but cannot commit those changes since that runs in the pre-commit hook. Any help or advice is appreciated!

[bamfix]

this would be exactly what i was looking for. looks great and seems to work just fine. these Codacy issues arent real issues as it seems? only false positive code conventions?

how long does it usually take for something like this to go live in bootstrap vue? this would make the difference for me between using the calendar from bootstrap vue or another third party package.

sry im new to vue, bootstrap and github.

[stale[bot]]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution.

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated
bootstrap-vue	✅ Ready (Inspect)	Visit Preview	Apr 28, 2022 at 8:59AM (UTC)