@bennypowers thanks for the PR, but I want to circle back to what I was suggesting in #146 comments

The spacing option was intentionally kept limited to avoid complexity.

I don't agree with allowing spacing: 'dedent'. That option got to stay simple as is. For all other transformations, I suggest applying them as in this example without touching top-level API. Indentation is not a parsing option but rather a transformation you apply to the tokenized source. So for the dedent it would look like

const { dedent } = transforms;
const parsed = parse(source);
const stringified = stringify(dedent(parsed[0]));

all config permutations handled in the main flow were a huge pain in 0.x version. On other hand, using flow() allows customizing the flow with interference

if you still willing to land this contribution, can we shape it after transforms/align.ts which is a pretty similar transformation? So it will boil down to

transforms/dedent.ts
tests/unit/transforms-align.spec.ts
tests/e2e/transforms.spec.js

doing so would require reimplementing dedent to take markers and return a Transform, when it's already implemented as string => string. What do you think?

Yes, dedent would have to be a function returning configured Transform. It's the already existing flow for align and indent, there is no good reason dedent should be one-off

Unfortunately I don't have the time right now to rewrite an existing package to suit the custom tokenizer that comment-parser uses. I think it would be a great feature but for now I'll have to apply workarounds like dedenting the output in my consuming code.

Thanks for considering this PR

@bennypowers no prob. Thanks for the feature suggestion, I will try to land it myself sometime.