Design for saving app version along with jspsych data

[benjamin-heasly]

Honeycomb gets the running app's version out of package.json and saves this value along with jspsych trial data. This ticket is here to:

• mention this as a use case
• mention how it currently works
• capture some design discussion that came up when upgrading Honeycomb to react-scripts 5 and webpack 5.

Previously, this used a named import like import { version } from '../package.json'. As of react-scripts 5 and webpack 5, this style of import throws a compile error similar to this:

Failed to compile.

Should not import the named export 'name' (imported as 'name') from default-exporting module (only default export is available soon)
ERROR in ./src/config/main.js 14:17-21
Should not import the named export 'name' (imported as 'name') from default-exporting module (only default export is available soon)

ERROR in ./src/config/main.js 15:20-27
Should not import the named export 'version' (imported as 'version') from default-exporting module (only default export is available soon)

webpack compiled with 2 errors

Currently, Honecomb works around this by importing the whole default from package.json, then accessing the fields it needs by name, similar to this:

import packageInfo from '../../package.json'
...
const taskName = packageInfo.name;
const taskVersion = packageInfo.version;

This is nice and simple/foolproof. But according to some, importing the whole package.json is not good security practics, as in this SO post.

One alternative could be use a postinstall script to scrape out just the name and version from package.json, write to a separate file, and import this instead. This is how Honeycomb currently accesses git version info, as in version.js. But this would add moving parts and would allow the scraped-out values to get out of sync with the true values in package.json.

Another alternative could be to look for environment variables provided by npm and get them wired in to where we need them, inspired by this SO post. We might need to reassign these to vars with the REACT_APP_ prefix in our .env files.
We might need a separate approach for the case of running via Electron.

IMO (@benjamin-heasly), none of these feels quite right, and it would be nice to find a solution that "just works" and doesn't feel like fighting the frameworks we're using!