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.

[shellscape]

@vladshcherbin this discussion is scoped to plugins in this repo, and since we want to get all plugins on TS here, we're safe. The wider discussion on how third party plugins should validate options is still relevant, but out of scope right here.

Another idea I had:

I think we're going to need a transform plugin to make this happen, but we could export a custom validate method(s) that pipe to superstruct so that the generated source could include a schema as an injected optional argument. It would require a peerDep on superstruct but that's probably a given.

// plugin source

export interface ValidateSchema {}

export validate = (obj: any) => {
  // check `args` here because we'll inject the schema as the second argument in any
  // calls to this method in the compiled code.
  const [,schema] = args;
  ...
}

// code

import { validate } from 'plugin';

interface Batman extends ValidateSchema {
  batcave: string;
}

const obj = { ... };

validate<Batman>(obj):

The transform plugin would

• look for the validate function signature
• examine the type argument
• assert it's an interface and extends ValidateSchema as an extra check
• generate a superstruct schema from the interface (TBD)
• modify the call so it would look like:

validate(obj, { ... schema ... });

Another option would be to use a decorator on the method, but because TS does't allow decorators outside of classes, we'd have to use a // @ts-ignore again:

// @ts-ignore
@Superstruct<Batman>
validate(obj)

Not really desirable because that removes all compiler checks from the decorator, and TS doesn't yet allow us to ignore individual errors.

[NotWoods]

I think the best option right now is to use superstruct and just have a little bit of duplication. We can have tests to ensure the validation matches the Typescript interface.

[shellscape]

Well that's no fun :)

[stale]

Hey folks. This issue hasn't received any traction for 60 days, so we're going to close this for housekeeping. If this is still an ongoing issue, please do consider contributing a Pull Request to resolve it. Further discussion is always welcome even with the issue closed. If anything actionable is posted in the comments, we'll consider reopening it.# Comment to post when closing a stale issue. ⓘ