Presently, the open Pull requests for cli-table3 are polluted with dependabot PRs that presumably could/should be auto-merging (upon passing CI tests). It looks like this may date back to the migration from dependabot-preview (see #216 and dependaot preview's history).
For longevity, cli-table3 should focus dependabot on it's pertinent dependencies* and minimize dependabot's interference with devDependencies as best as possible.
* cli-table3 has only one production dependency (string-width), one optional dependency (@colors/colors), and one dev dependency (cli-table) whose version is relevant.
cli-table3 (this module) presently offers "backwards" compatibility with cli-table—and includes tests to prove it. Yet, these interfacing tests are more accurately "continuous" (see #196 & #283) while the devDependency on cli-table is not fixed to a specific version in package.json.
Because cli-table3 relies upon cli-table within it's tests and only within it's tests, there is a question: Which versions of cli-table are intended to be supported by cli-table3? If true backward-compatibility is intended, as seems to be the intention demonstrated, we could/should lock on a version and call it true. But presently, it's not backward (locked), it's continuous. This is relevant, I think, to get dependabot honed appropriately.
Despite activity or not on cli-table, I don't think the intention with cli-table3 is nor ever was to keep up with API changes that might occur to cli-table in the future. It would be possible to support both "true backward" and "continuous"—but testing advancements to cli-table would merely be testing breaking API changes to cli-table and not cli-table3.
To keep it simple here, we'll just lock cli-table to a specific version.
With that in mind, it seems like the following would be ideal for leveraging dependabot:
(Prod) Dependencies
"Dependencies" is presently singular; cli-table3 relies only on: string-width
[ ] dependabot auto-mergesminor and patch releases
[ ] dependabot creates pr requiring manual merge for major releases [until told otherwise]
These should be demonstrable by: dependabot automatically raising string-width to the latest 4.x version and creating a pr for the 5.x version.
Dev Dependencies
[ ] Lock cli-table to specific version in package.json
[ ] dependabot ignoresmajor releases and cli-table
[ ] dependabot auto-mergesminor and patch releases (pending CI tests)
These should be demonstrable by:
dependabot not creating PRs for major releases (presently: eslint-config-prettier, eslint-plugin-prettier, etc.)
dependabot auto-merging devDependences for minor and patch releases.
Summary
The end results here should be:
Minor and Patch updates for all dependencies automatically processed by dependabot.
Pull-requests free of dependabot PRs—except major releases to string-width.
Locking of cli-table and dependabot ignoring it completely.
Presently, the open Pull requests for cli-table3 are polluted with dependabot PRs that presumably could/should be auto-merging (upon passing CI tests). It looks like this may date back to the migration from
dependabot-preview(see #216 and dependaot preview's history).For longevity, cli-table3 should focus dependabot on it's pertinent dependencies* and minimize dependabot's interference with devDependencies as best as possible.
* cli-table3 has only one production dependency (string-width), one optional dependency (@colors/colors), and one dev dependency (cli-table) whose version is relevant.
cli-table3 (this module) presently offers "backwards" compatibility with cli-table—and includes tests to prove it. Yet, these interfacing tests are more accurately "continuous" (see #196 & #283) while the devDependency on cli-table is not fixed to a specific version in package.json.
Because cli-table3 relies upon cli-table within it's tests and only within it's tests, there is a question: Which versions of cli-table are intended to be supported by cli-table3? If true backward-compatibility is intended, as seems to be the intention demonstrated, we could/should lock on a version and call it true. But presently, it's not backward (locked), it's continuous. This is relevant, I think, to get dependabot honed appropriately.
Despite activity or not on cli-table, I don't think the intention with cli-table3 is nor ever was to keep up with API changes that might occur to cli-table in the future. It would be possible to support both "true backward" and "continuous"—but testing advancements to cli-table would merely be testing breaking API changes to cli-table and not cli-table3.
To keep it simple here, we'll just lock cli-table to a specific version.
With that in mind, it seems like the following would be ideal for leveraging dependabot:
(Prod) Dependencies
"Dependencies" is presently singular; cli-table3 relies only on: string-width
These should be demonstrable by: dependabot automatically raising string-width to the latest 4.x version and creating a pr for the 5.x version.
Dev Dependencies
These should be demonstrable by:
Summary
The end results here should be: