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.

Update Parser #145

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions