fix(natives): Vector3 will generate a tuple type instead of an array …

[AleksanderEvensen]

Goal of this PR

The vector3 type has until now been generated as an array type. In my opinion it should be generated as a tuple type instead.
The reason I think the tuple type is a better option is because it can be used properly with the spread operator in functions that takes in the x, y and z component (ref picture below)

How is this PR achieving the goal

Changing the codegen for dts files to parse the Vector3 type into the tuple type

This PR applies to the following area(s)

Natives

Successfully tested on

Has not been tested due to node-gyp not being able to compile the libclang bindings in native-doc-tooling

Game builds: N/A

Platforms: Windows

Checklist

• Code compiles and has been tested successfully.
• Code explains itself well and/or is documented.
• My commit message explains what the changes do and what they are for.
• No extra compilation warnings are added by these changes. (I won't expect it to generate any errors due to the small change, but I'll leave it uncheck since i haven't tested it)

Fixes issues

N/A

[AvarianKnight]

I think this would be better, though it would generate type errors where there were none before, but also not sure what the opinions on "compatibility breaks" are for types.

I think this change is better for the better as it should always return 3 values

[AleksanderEvensen]

I didn't even think about the compatibility breaking for the types 😅

[FabianTerhorst]

I'm not sure if we can handle this change considering it causes to much compatibility issues.

[AleksanderEvensen]

This could be done by a major version bump to the package (if that isn't off the table).

Using a tuple type in a function that takes an array as parameter doesn't yield an error in TypeScript.
The only instance where TypeScript yields an error is when an array is passed to a function where the parameter is a tuple type. I haven't seen any function in the type definitions for the natives where a function takes an array as input, so compatibility with other natives wouldn't break.

Error in user code wouldn't be a problem either, because if they're using a tuple type in their own functions they're also typecasting the array type anyway.

Would therefor argue that this wouldn't break so many things that I might have thought in the beginning.

Maybe some weird eslint rule would catch this case, but I didn't have the time to test this right now. If there is anything else that i might have missed, I would love to hear about it.

tsconfig used with example above:

{
    "compilerOptions": {
      "strict": true,
      "allowUnusedLabels": false,
      "allowUnreachableCode": false,
      "exactOptionalPropertyTypes": true,
      "noFallthroughCasesInSwitch": true,
      "noImplicitOverride": true,
      "noImplicitReturns": true,
      "noPropertyAccessFromIndexSignature": true,
      "noUncheckedIndexedAccess": true,
      "noUnusedLocals": true,
      "noUnusedParameters": true,
  
      "isolatedModules": true,
  
      "checkJs": true,
  
      "esModuleInterop": true,
      "skipLibCheck": true
    },
    "$schema": "https://json.schemastore.org/tsconfig",
    "_version": "2.0.0"
  }

[FabianTerhorst]

Thanks for the explanation. When the array typed function parameter accepts the tuple as well its not really a compatibility issue.