Repo: Validate Options

[shellscape]

• Rollup Plugin Name: all
• Rollup Plugin Version: current

Feature Use Case

We have a lot of code in different plugins - and then none at all in many - which attempts to validate plugin options in various different ways. Unifying how plugin options are validated, asserting that they'r validated in each plugin, and unifying messaging around invalid options would be a benefit to users and maintenance alike.

Feature Proposal

I'd like to propose @hapi/joi for this purpose. I have some experience using that and working with their community and it was pretty smooth. Of course, open to suggestions. Using pluginutils, we can create a common API to facilitate this.

[NotWoods]

I'm happy to add runtime validation, but I don't want to use joi since its big and can't be tree-shaken.

I like superstruct, which has a super simple API and lets you add additional validator that just return a boolean. Then pluginutils can just export functions that return true or false, making it easy to reuse with other validation systems if desired.

I'd also be happy with yup, which has a similar API to joi but uses ESM.

[shellscape]

but I don't want to use joi since its big and can't be tree-shaken.

Curious, why does tree shakeable matter if we're not tree shaking?

[NotWoods]

I think we might want to, since we only use a subset of the validators. If we ship Joi in the plugins separately instead of any plugin using pluginutils then it's less important.

[shellscape]

This may be a philosophical thing. I know that Rollup is big on shipping a small package. But these are, at the end of the day, devDeps that are never included in the final bundle from the consumer. I just can't see the importance of size of pluginutils. Besides, that can be shipped as an external / normal dependency, and there will (in theory) only ever be one instance of @hapi/joi on disk.

@hapi/joi is 560kb
yup is 2.37mb
superstruct is 538kb

Now, what I am interested in is speed. Because a build being fast is vastly more important than the size of pluginutils. I'll probably have to redo the benchmarks from a while back, but when I measured, joi was significantly faster than yup. joi is used across most of the hapi ecosystem, so it kind of has to be fast, as well as well-supported.

For superstruct, I have the same issues with that which I had with ajv. I much prefer the functional declarations for validation than I do the schema-based declarations.

[NotWoods]

I was using bundlephobia to check, so I wasn't aware that superstruct is a similar size to joi (it looked much smaller). I'm convinced, let's use Joi.

[shellscape]

Since the last time the issue was active I've kept an eye on development of yup vs joi and I'm not a big fan of the direction that joi has been heading in. I like the verbose output of errors for superstruct so I think it's work a look. It's a damn shame that nothing exists which could transform a TS interface into a validator function with all the same goodies as the others.

[NotWoods]

The only way to use TypeScript types after compilation is with decorators. If we want to go down that path, we could put together something like this:

import { validate } from '@rollup/validate';

@validate
export function nodeResolve(options: RollupNodeResolveOptions) {
  ...
}

// tsconfig.json
{
  "compilerOptions": {
    "experimentalDecorators": true,
    "emitDecoratorMetadata": true
  }
}

[shellscape]

So TS doesn't allow decorators on interfaces unfortunately. The best I've been able to come up with is a transform plugin, and having to ignore the "Decorators cannot go here" error in the source:

// source

// @ts-ignore
@Superstruct()
interface Batman {
  batcave: string;
}

// plugin

import ts from 'typescript';

export default function() {
  function visit(ctx: ts.TransformationContext) {
    const visitor: ts.Visitor = (node: ts.Node): ts.VisitResult<typeof node> => {
      if (ts.isInterfaceDeclaration(node) && node.decorators.length) {
        const [decorator] = node.decorators;
        const identifier = decorator.expression.getFirstToken() as ts.Identifier;

        if (identifier.escapedText === 'Superstruct') {
          console.log('found');
        }
      }
      return ts.visitEachChild(node, visitor, ctx);
    };

    return visitor;
  }
  return (ctx: ts.TransformationContext): ts.Transformer<ts.SourceFile> => (sf: ts.SourceFile) =>
    ts.visitNode(sf, visit(ctx));
}

This only gets us so far though. If we render a schema object based on this, we still have to be able to reference it in code before compilation. And I haven't figured out how to do that.

[vladshcherbin]

Don't forget not everyone is using TS in plugins, such validation would be nice for js plugins as well.

Here is related issue I've opened in rollup for same kind of checks - rollup/rollup#3159

[Andarist]

@vladshcherbin this issue is about adding runtime validation as well.