I don't have a plan for when to do a v8 release, other than ideally not soon. I find that having semver breaking versions too frequently can cause pain for consumers, and many will often not update. Only 10% of users have updated to v7 after 12 months, while 75% have updated to the latest patch release of v6 in the 16 months after it was released.

Feel free to suggest any ideas of breaking changes you would like to see. Either as a short idea that could be added to this list or a link to an issue if it needs more explanation.

Some of this could be done by adding a second cmake-js2 executable to v7, so that it can be done sooner without needing the v8 bump. In v8 the executables would then be renamed so that cmake-js uses the 'new' flow.

Ideas I think should be done:

• ✅ Consider updating minimum nodejs requirement. This needs some thought on what the new minimum should be, and if it should change at all. https://github.com/awslabs/aws-crt-nodejs is one of the larger users of this project and don't update their minimum often. As of writing, they have just dropped nodejs 10, 2.5 years after it went EOL. Their new minimum is nodejs 14, which was EOL 6 months ago. This should also be influenced by our dependencies, factoring what their current minimum is, and some thought on when will we get stuck on unsupported versions.
  • Builtin fetch support from node 18 would be nice to have to reduce the dependency footprint.
• ✅ Projects should be assumed to be node-api based unless detected/specified otherwise. This flips the default behaviour, but will better indicate that node-api project should be preferred and are the future.
• ✅ Rewrite the project in Typescript or ES classes. This would help with maintainability and readability of the code, but will likely be a breaking change for anyone using cmake-js programatically (is that even possible/supported?). As a sub portion of this, should we switch to ESM instead of commonjs? Maybe this could be done as a minor version, we don't claim to have a programmatic api...
• ✅ Rework logic to be done via loadable cmake modules instead of injecting variables. The aim is to be able to perform the build with standard cmake, and to avoid the various snippets of cmake config we require users to add to their cmake files. This might help simplify the codebase, depending on how much logic we can conclude is no longer necessary.
• ✅ Review the existing command line parameters. Can it be changed to use the same keys as cmake? When coupled with Rework logic to be done via loadable cmake modules, could cmake-js simply be a helper to locate and invoke cmake with a sensible generator with all other arguments passed through?

Ideas I am not sure about:

• ⛔ Deprecate support for non node-api projects? As I see it, these projects are 'legacy' and there is no good reason to make a new one in this format. But there are likely many users who cannot justify the cost to port their project to node-api. Deprecating this could give them a needed nudge, or could just annoy them. If this is done, the earliest that support could be dropped is v9 unless there is enough objection.
• ✅ I do not understand the usecase for much of the config field in package.json. Perhaps some work should be done to identify what portions are useful and clarify the intended use case in the documentation.