Property "values" missing when Inspecting InsertQuery ValuesNode

KNKristian Notari2/20/2023
I'm having some troubles upgrading from 0.22.0 to 0.23.4, because I have a custom plugin which gets some columns as input for each database table and prevent any other column to be used as the target of an InsertQuery (this way I can silently pass { id: 42, username: "John", nonExistingColumn: "error at runtime" } as an insert value for my user table without worrying about excessive properties in the values.

I have overriden the:
protected override transformInsertQuery(_node: InsertQueryNode): InsertQueryNode

and before the upgrade I was checking if my insert query values are actual values I need to filter to remove values for non existing columns but right now I have this error saying there's no values property inside the values node:
const newValues = node.values?.kind === `ValuesNode` ? transformValues(node.values) : ...

This is due to the node.values being a OperationNode which only has:
export interface OperationNode {
    readonly kind: OperationNodeKind;

There used to be a ValuesNode instead, after checking for its kind "ValuesNode". But now it's just an OperationNode and I can't access values directly.
export interface ValuesNode extends OperationNode {
    readonly kind: 'ValuesNode';
    readonly values: ReadonlyArray<ValuesItemNode>;

Do you know how to solve?
You can use the function for the check. Then you'll have the correct type.
KNKristian Notari2/21/2023
Ok so basically there has been a change where the nodes are considered simple "OperationNodes" and then you have to check if something is something by a guard specific for each node you'd like to check for, even if the type is not present in the target node types. I mean, it's there string-wise in the "kind" property, but that's not a discriminant type-wise, you need the guard now. Is that correct?
There have been changes from explicit node type unions to OperationNode in places where the node type can be a large number of types. Listing them all as a union no longer made sense.
If we defined OperationNode as the union of all possible nodes, then a simple node.kind === Something would work as a guard. Currently OperationNode is defined as { kind: OperationNodeKind }.
But it's been like this from the beginning. The only thing that's changed is widening of some node types from union of possibilities to OperationNode.
KNKristian Notari2/21/2023
yeah ok so using the guard of the specific node you need is the only option but there's nothing preventing me from using another guard, one of a node which is not listed in the kind of nodes available in such OperationNode (if this case exists at all), right?