Fixes #329

[hildjj]

I'd like someone with more TypeScript intuition to think about how much this breaks things. I realize that it means that we're not going to get as good type checking on known parameters, but this is what we get for having inherited an API.

[reverofevil]

Won't break much, but in general index signatures are not very stable. The correct approach to pass options to plugins looks like this:

import { generate } from 'peggy';
import { goodPlugin } from 'good-plugin';

const code = generate({
    // peggy options
    plugins: [
        goodPlugin({
            // plugin options
        })
    ],
})

A good real-world example is webpack's API vs vite's API. At the very least, there is no guarantee two plugins won't use same top-level key for different purposes.

[hildjj]

I agree that this would have been the right approach if we were designing the API, but I don't think breaking existing plugins is warranted for this change.

[reverofevil]

Let's make a plan on how to phase out old API. A good start would be to review this PR. It highlights several problems of typing the existing API.

[hildjj]

I agree we need a plan, and I'm ok with moving to typescript as a part of a larger breaking change. I think the next step is a discussion of how we generate code (which will cause a massive downstream breakage if we change anything), then figuring out what else we're going to break at the same time. I'm working on writing something up about code generation.

[reverofevil]

Linked PR adds TS without breaking changes (although I didn't test it). The point in reviewing the PR is to get an idea of where types get especially gnarly, and of which things we'd like to avoid. For example, codegen there isn't that pretty either.