chore(common): improve configuration detection for hextobin

[ermshiperete]

This improves #12440. The previous change was a bit fragile if we updated commander versions. This change now implements a better solution that doesn't rely on dependencies and their locations for detecting if we need to run the configure action for hextobin.

@keymanapp-test-bot skip

[keymanapp-test-bot]

User Test Results

Test specification and instructions

User tests are not required

Test Artifacts

• Developer
  • Keyman Developer
  • Compiler Regression Tests
  • kmcomp.zip
• Keyboards
  • Test Keyboards
• Windows
  • Keyman for Windows
  • FirstVoices Keyboards for Windows
  • Text Editor (32 bit)
  • Text Editor (64 bit)

[mcdurdin]

Yes, this is more robust, and I see how you have set this up to work on win + mac + linux. I understand you are adding it as a postinstall script so that any npm ci anywhere in the tree will cause the .configured file to be created.

Conversely, if you rm -rf node_modules now, the configure action will no longer be run. So we win some, lose some.

And this issue is more systemic than just hextobin, of course. Do you see us doing the same thing for all node projects? My main concern is that the node script is a little bit of slightly icky boilerplate to copy everywhere.

If we moved the .configured file out of the build folder, and added it to the global .gitignore, then we could do it cross-platform without node:

  "postinstall": "echo configured > .configured"

[ermshiperete]

Do you see us doing the same thing for all node projects?

This is only necessary for node projects that either have 1) a local node_modules directory, or 2) are a dependency for a project in another subtree (e.g. common/tools/hextobin being a dependency for projects under core, although in that case it also has a local node_modules). Reason for 1 is that the local node_modules might not exist after cleaning the subtree. Reason for 2 is that the global node_modules likely has a link to the no-longer existing build directory after cleaning the subtree.

Hmm, maybe it's necessary for all node projects that serve as a dependency? But so far I never had problems if the dependency was in the same subtree, but that might have been luck. We'll see...