Suggestions of naming conventions for third party ppx attributes

1

Unlike extension points, unused attributes will not trigger a warning or error by default.
This can cause some subtle bugs if user makes a typo.

For example,

@derivi // typo, it is expected to be derive
let f = (x)=> x + 1

Such typos can not be caught by the type checker. We used to have warnings for unused attributes, however, it could cause false alarm for third party ppx attributes since we don’t know if derivi is used by third party or not.

Ideally, third party ppx should drop those attributes after processing, but this does not happen in practice or is hard to enforce.

So we suggest third party ppx always introduce the attributes under a namespace. Take graphql for example, all its attribute names could come after gql.**. In this case, we don’t warn unused attributes with a customized namespace, we only warn unused attributes if it does not come with a namespace, since we have some built-in knowledge about them.

As always, create a ppx only when you really need it, this post is not to encourage people to create ppx.

2 Likes
2

We only use extension points! All other configuration is using decorators in GraphQL.

3

Doesn’t it make sense to keep annotation around. For instance you’d probably want to keep the @react.component attribute so that subsequent ppx-es know what is a react component. I can imagine for instance a documentation generator that detects react components by the annotation.

4 Likes