search

RobLoach / node-raylib

Node.js bindings for Raylib
https://robloach.github.io/node-raylib/
Other
237 stars 20 forks source link

Update to raylib 4 #119

Closed RobLoach closed 2 years ago

konsumer commented 2 years ago

I'd still like to fix up these CI builds a bit before merge/publish. I will work on this today, and make sure the script is grabbing the right stuff on install. This drastically changes what will happen on npm install for most people, so I really want to make sure I have it right before we push out a new major-number & publish on npm.

The matrix-thing is cool, but it seems like maybe I should reduce the surface-area (only 1 supported node version, etc) and include arch in the names (and account for that in the install-script.)

I'd also like to figure out how to cross-build for arm32/64 (primarily for pi and mac M1) but that might not get in this merge (seems really complicated.) I could still hand-upload for the arches I have access to (osx M1 arm64 and pi arm32.) Non-x64 users will still build their own copy locally, sort of like it was before, so we aren't dropping them (it has the same support as before) but it will take a bit longer to install than the new stuff.

I'm also not sure if we landed on how raylib is installed on the user's system. I am a big fan of instructions that are essentially like "install raylib like this" for each target, and leave distro of that part up to raylib project (they have their own nice CI and website, etc) but this would be a bit different than how node-raylib was setup, before. It's also possible it would not use the exactly right version of raylib (maybe the raylib version should also go in the prebuild name?) @twuky @RobLoach what do you think?

I'd also like to add "alpha" npm releases and make sure it works, so we can test CI/publish stuff before it's ready (they are not installed when a user runs npm install, unless they specify the exact alpha.)

Additionally, I should put better "node-raylib developer" instructions in README or somewhere, about forcing a local build (no CI prebuilds) since this will be really important for working on node-raylib, but most people will just get the latest release pre-builds.

Also, to recap (I think we talked about it on discord, but here is some notes), a new release should go like this:

# make sure git repo is in completely tracked state, with no untracked changes
npm add -A
git commit -am "preparing for release"

# this modifies package.json version, commits, and tags git repo with same version
npm version patch

# this pushes the commits & tags to github, which triggers CI to publish to npm
git push --follow-tags

patch could also be minor or major depending on the type of change (see semver.) In our first tagged release, it should be major. The purpose of this is so the end-user/us can always find the exact tagged source that created a release, and anyone with push rights for tags can publish to npm (so you can even remove us from npm collab-list, @RobLoach ) This may require config in gitlab (need to add npm token, and make sure it works.)

konsumer commented 2 years ago

More on releases:

I removed node 12/14 as the same build should work for all of them. If we want to test later, we can do a separate action that builds for them all but makes no artifacts.

Currently the postinstall script looks for proper github releases, but the github action just makes assets (not attached to any tag/release, just attached to the action-run.) I think i should add to this action that it does an actual release, and only do it on tag (so only tags get built/released.)