Proper way to extract AST schema from @babel/types

[jedwards1211]

I've been extracting the AST schema from @babel/types by looking at NODE_FIELDS and the validate function of each field. I've proposed using this in ast-types to ensure that it's using the same AST schema as Babel does, and I do the same thing in https://github.com/codemodsquad/astx.

But my question is, can I rely on this? Are the properties of validate intended to be stable, publically-consumable API or not? If not, is there any better way, or can we work on making a public API for getting complete information about the AST schema?

[liuxingbaoyu]

Seems not, it's an internal implementation detail as I understand it.
What do you want to use it for? Node attribute information? Check node legitimacy? Node parent-child relationship?

[jedwards1211]

@liuxingbaoyu I'm not sure what that's used for but it seems like ALIAS_KEYS probably gives me information I can use in the same way? For example I'm able to use it to declare what node types are considered an Expression in the ast-types schema

[liuxingbaoyu]

It looks like NODE_PARENT_VALIDATIONS is not.
Is the information provided by ALIAS_KEYS enough? There is compatibility support for this.

[liuxingbaoyu]

Well, I re-looked at the code and the type definitions are being exported, not sure if someone ever decided to expose it, but it is now.
But it would be better if you could use ALIAS_KEYS, which is much more stable.

[jedwards1211]

Yes ALIAS_KEYS works well. Right now I'm more concerned about properties on validate changing. Right now the only way I've found to determine the type of a node field is:

    if (validate.type) {
      switch (validate.type) {
        case 'any':
          return {}
        case 'string':
          return builtInTypes.string
        case 'boolean':
          return builtInTypes.boolean
        case 'number':
          return builtInTypes.number
        case 'null':
          return builtInTypes.null
        case 'undefined':
          return builtInTypes.undefined
      }
    }
    if (validate.chainOf) {
      for (const elem of validate.chainOf) {
        const converted = tryConvertValidate(elem)
        if (converted) return converted
      }
    }
    if (validate.each) {
      return [convertValidate(validate.each)]
    }
    if (validate.oneOfNodeTypes) {
      return or(...validate.oneOfNodeTypes.map((type: string) => def(type)))
    }
    if (validate.oneOf) {
      return node?.optional
        ? or(...validate.oneOf, null)
        : or(...validate.oneOf)
    }
    if (validate.shapeOf) {
      return mapValues(validate.shapeOf, (value) =>
        convertValidate(value.validate, value)
      )
    }
    if (validate.oneOfNodeOrValueTypes) {
      return or(
        ...validate.oneOfNodeOrValueTypes.map((type: string) =>
          /^[A-Z]/.test(type) ? def(type) : convertValidate({ type })
        )
      )
    }

Where validate is coming from

  for (const [type, fields] of Object.entries(t.NODE_FIELDS)) {
    for (const [field, { validate }] of Object.entries(fields)) {
      ...
    }
  }

[liuxingbaoyu]

I didn't think of a good way, because even if we add a new verification method here, it may break compatibility.(I don't think it is very likely)
But for now, I think this way is also possible, simple enough. And we can also mention ast-types or you if we change these in the future.