Configure Publishing OSCAL Viewer to GitHub Packages

[hreineck]

Set up package.json and GitHub actions to publish to GitHub packages.

[hreineck]

This and the corresponding PR in oscal-rest-service handle setting up GitHub packages as part of the all-in-one deployment.
Once the changes to package.json are made, the package can be published by simply running npm publish with necessary credentials - but I figured a formalized GitHub actions would be better and more reviewable.

[hreineck]

Not sure about this change. I thought it needed to be removed in order to publish - can someone clarify what this line was doing or if it's still necessary?

[kylelaker]

I have a few questions here since we're talking about the example application (not library). I think all of this would be absolutely phenomenal for the React Library at the root but we may want to think about the design a bit for the example app.

1. Is it really appropriate to deploy the example app to GitHub Packages? It's more of a static asset after an npm run build and we can just deploy the examples/build folder directly. Do we really care about the full contents of the NPM package and do those provide us any benefit anyway? Perhaps we'd be better served by actions/upload-artifact rather than by publishing. Will it provide any benefit inside a node_modules/ folder? I believe we're actually already pushing that as an artifact: https://github.com/EasyDynamics/oscal-react-library/actions/runs/1174249533.
2. If we're going to go to this effort to publish the example app, should we configure the library to be published to GitHub Packages while we're setting this workflow up? We can always switch to a "real"/default registry like NPM's later but this would let us have a place to pull down snapshot versions of the library.

[hreineck]

I have a few questions here since we're talking about the example application (not library). I think all of this would be absolutely phenomenal for the React Library at the root but we may want to think about the design a bit for the example app.

1. Is it really appropriate to deploy the example app to GitHub Packages? It's more of a static asset after an npm run build and we can just deploy the examples/build folder directly. Do we really care about the full contents of the NPM package and do those provide us any benefit anyway? Perhaps we'd be better served by actions/upload-artifact rather than by publishing. Will it provide any benefit inside a node_modules/ folder? I believe we're actually already pushing that as an artifact: https://github.com/EasyDynamics/oscal-react-library/actions/runs/1174249533.

We don't really care about anything but the static output of build, but GitHub Packages may still be a good option since we will eventually be setting up a pipeline to deploy the library to a registry anyway.
If there's nothing explicitly wrong with publishing the entire app, I think it may be simpler to keep using the current approach;
the upload-artifacts action seems to be geared more towards sharing artifacts within a single worklow. I could only find this third-party action: https://github.com/dawidd6/action-download-artifact to be able to download from one repo to another.
Would like to know what the team thinks of this - if the approach using artifacts seems better we can certainly use that instead.

2. If we're going to go to this effort to publish the example app, should we configure the library to be published to GitHub Packages while we're setting this workflow up? We can always switch to a "real"/default registry like NPM's later but this would let us have a place to pull down snapshot versions of the library.

Good call.

[mikeisen1]

Everything looks good to go. Nice work!