Update Parser

[RobLoach]

raylib_api.json now includes...

• Aliases
• FLOAT_MATH instead of UNKNOWN
• Actual Matrix

[twuky]

Those new things will need to be looked into for sure.

At the current moment - this new raylib_api.json file is not consisent with raylib 4.0's API - its more indicative of raylib 4.1 really, which isn't a currently tagged release for raylib. Some function names and parameter types have been changed since 4.0 released.

Right now Cmake-JS pulls down the 4.0 git tagged raylib, so we also need to use the JSON file associated with that or we can't build properly. Currently the parser grabs a specific version of the api to ensure compatibility with what cmake uses.

So I think currently we only need to update the parser if either a new release / git tag of raylib comes out.

We could try working on writing things so they are always in sync with the main raylib github branch. but because of the generator / build system that would mean the API of the npm package would not be deterministic based on version any more?

[twuky]

Possibly a better way to go about this is to simply include the version of the JSON in this repo, but I wasn't sure how that would act with raylib's license, so at the moment it pulls it with fetch().

In general I should maybe document what is / will be needed to update the parser/generator with new raylib updates. Right now the steps look like:

• Update CMakelists
• Update parser to use newer JSON file
• Potentially update parser/generator code to accommodate new features
• Update npm version to trigger new CI build/releases

[konsumer]

I added the download of the json, just because I don't like including derived, referenced, or built things as copies, in git. I like it when everything can be tracked back to it's file-history, issue-queue, CI action, etc, so personally I am a bit opposed to including the json file, if it doesn't simplify things or have any other benefits.

It uses a specific commit-hash to lock it into a specific version, so I think we can pair the JSON api/node-raylib fine by just updating the hash to be whatever the script can build for. If we want to support 4.1 in generator, we can just update the hash & generator code, all in 1 go.

If there needs to be cmake updates, we can lock in a specific commit hash in a similar way, so cmake builds off the same raylib version.

A version tag (npm version patch/minor/major) will trigger CI to build.

Maybe we should use a package.json field for raylib-git-hash? a trick that happens from anything run inside npm is that it sets enviroment-variables, so it could be used easily in cmake or generate from 1 field, and it would also be a way for users to check what raylib API is used, if needed.

{
  "config": {
    "raylib": "2e3cfdcc2f5c70e82536caa57d4aa72e3f00fd4"
  }
}

npm_package_config_raylib=2e3cfdcc2f5c70e82536caa57d4aa72e3f00fd4

I think it specifically needs to be inside config but otherwise you can name it whatever you want.

[twuky]

The only issue with it as it is now is that it can be a bit cumbersome to actually find the right commit to use. the JSON file is not updated automatically in raylib's repo - so it only gets updated when someone manually runs the tool and decides to commit the result.

Maybe we can get our CI system to self-publish the JSON file and uploaded to releases like it does our native addon files. Then node-raylib doesn't have to pull anything from an "uncontrolled" environment when parsing/generating?

[konsumer]

The only issue with it as it is now is that it can be a bit cumbersome to actually find the right commit to use. the JSON file is not updated automatically in raylib's repo - so it only gets updated when someone manually runs the tool and decides to commit the result.

Yeh, and they don't seem to tag until it's finished, and generate when they are doing a release, which makes sense, but is maybe an argument to work on this as a future-thing (to anticpate the API changes before 4.1 is released) but not tag for current release of node-raylib.

If you don't tag, it doesn't release, so it could just be a branch of code that floats around until 4.1 gets released. We could also use npm tags to create pre-releases (they don't automatically install when you do npm i raylib, but are easy if you know the name: npm i raylib@0.9.1-beta-4.1-1) and that can all be used with CI, as it is (by tagging v0.9.1-beta-4.1-1 for example.)

[RobLoach]

Built it manually against 4.0.0 over at https://gist.github.com/RobLoach/61477c6ff34764e1c3962031d4dd3f8c ... K.I.S.S :wink:

Was experimenting with a PR over at https://github.com/RobLoach/node-raylib/pull/148 . Also just made a repository for all the latest exports based on 4.0.0: https://github.com/RobLoach/raylib_api