Christopher Hiller

mdx files in `docs` package need linting. this would avoid some dumb mistakes. see https://npm.im/eslint-plugin-mdx

I know that `,` as the delimiter can be problematic in Europe, so allowing `;` would be helpful here.

Right now `list-rules` is its own command. Rules are only applicable when using `inspect`, so maybe it makes more sense to have `--list-rules` retain its behavior but instead be an...

sorting output should be done in the CLI

2

Currently, sorting is done in the core API (`toReportFromObject`), which doesn't make a lot of sense: 1. sorting must concatenate the stream to an array, which means there's a bottleneck...

disallow some configuration & transformer chaining

1

Normally I wouldn't go for this, as I like to give the user a lot of control, but I think we're doing way too much work to support every potential...

json transformer should use field labels

1

wherever possible, use the field labels instead of properties in the json transformer `list-rules` command should have keys `rule` and `description`, not `id` and `description`. (note that the keys should...

Add an ESLint rule that bans use of `_` exported from `@gnostic/common`. These are aimed to be good examples for users to write their own rules, and as such, we...

the camelCasing is awkward and, I think, inconsistent. if there are other places where camelCase is used, change those too.

There's a lot of `any` types still hanging around in here. because it's not yet documented how a user can create a plugin, documentation of the `Transformer` API was not...

Most of report-toolkit is written in a functionalesque style, using RxJS. but there are a few classes hanging around. generally, there's no mutation of these objects after construction--everything excepting `Transformer`...