-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
feat: add BOOTSTRAP_VUE_NO_WARN environment variable to hide warnings #2826
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
I'm happy to provide documentation and tests (if wanted) in case this is an acceptable way to solve the problem. In case there are other ways to provide a global config, I'm happy to hear and change this approach. |
Codecov Report
@@ Coverage Diff @@
## dev #2826 +/- ##
==========================================
+ Coverage 90.78% 90.78% +<.01%
==========================================
Files 202 202
Lines 3234 3235 +1
Branches 971 972 +1
==========================================
+ Hits 2936 2937 +1
Misses 215 215
Partials 83 83
Continue to review full report at Codecov.
|
@tmorehouse I have squashed the commits now and added tests. I'm not quite sure where the docs would go though. Do you have a suggestion? |
@gitlab-winnie I think this is ready for merging. I'm not sure where this should be documented. I think maybe a new reference section page on miscellaneous settings? |
Added some rudimentary documentation. |
Thank you @tmorehouse and @jackmu95 for completing this! ❤️ |
Description of Pull Request:
This uses an environment variable
BOOTSTRAP_VUE_NO_WARN
to hide warnings logged by Boostrap Vue. This is useful in a test environment when incomplete test setup leads to false positives or in a production environment.A second iteration of this would be to add a config option similar to
Vue.config.warnHandler
to allow making tests fail.PR checklist:
What kind of change does this PR introduce? (check at least one)
Does this PR introduce a breaking change? (check one)
The PR fulfills these requirements:
dev
branch, not themaster
branchfixes #xxxx[,#xxxx]
, where "xxxx" is the issue number)and adding a new feature, break them into separate PRs if at all possible.
Conventional Commits naming convention (i.e.
"fix(alert): not alerting during SSR render", "docs(badge): Updated pill examples, fix typos",
"chore: fix typo in docs", etc). This is very important, as the
CHANGELOG
is generatedfrom these messages.
If new features/enhancement/fixes are added or changed:
package.json
for slot andevent changes)
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:
suggestion issue first and wait for approval before working on it)