document best practices for CI/CD for react-based htmlwidgets

[maxheld83]

I'm trying to run CI/CD (with GitHub actions) on a nascent htmlwidgets package for a react library, ideally without any derived files in the commits.

So in addition to the system requirements in #36, I'm running yarn install, and yarn run webpack --mode=development in CICD as well as gitignore the crosscompiled js in inst/htmlwidgets.

This keeps the commits lean, and seems to work ok so far: here's the action running off of this github actions workflow.

This way of doing things of course breaks anything like remotes::install_github().

What are your suggestions for best CI/CD practices? Am I on the wrong track here?

With some guidance, I'd be happy to add a section about this to the vignette in a PR.

[alandipert]

Hi Max, do I understand correctly that your goal is to keep compiled JS out of the git repo? Are you pursuing this in order to keep the repo size down?

I'm not sure it's something we should recommend to everyone, since I imagine for most people the burden of a slightly larger git repo does not override the convenience of remotes::install_github()

That said, it's an awesome thing to document if you're willing, and I think has applicability beyond reactR. Pretty much any htmlwidget/Shiny development that involves JS transforms or linting of some kind could benefit from an established workflow.

I'm no Github Actions experts but your .yml makes sense to me and looks similar to what I've seen done in Travis setups.

One thing you might consider is a step to "deploy" the built package file as a Github release, or otherwise make it available as something that could be consumed via remotes::install_url(). That way compiled JS is not in git but users still have an easy way to install development builds without compiling themselves locally.

[maxheld83]

Thanks, great idea(s).

My concern wasn't with repo size, but I just really dislike having programmatically generated files inside my commits; makes it hard to parse the diffs. Roxygenized /man/ is already driving me crazy 😅.

Makes sense though that the tradeoff might not be worth it for most users.

I'll look into GitHub Releases (or, I guess, GitHub Package Manager would be ideal for this -- if it ever supports R packages).

[maxheld83]

I did come across a suggestion to use configure pre-build hooks for this kind of thing (?), but it would probably add too much complexity either way.

[alandipert]

Oh, re: diffs there is a way to configure git (via .gitattributes) to mark files in the tree 'binary', and then they won't blow up your diffs.

Even so I think there is advantage to keeping generating code out of git. Other than for size, for security and reproducibility; it's very hard to know if e.g. the generated code associated with a PR is free of exploits, and was generated by a means that can be reproduced.

On Shiny, for instance, we keep generated code in the repo but have to remember to periodically regenerate it by trusted means. Beyond the inconvenience of having to remember to do this, doing so can cause merge conflicts that waste time to deal with.

GitHub Package Manager is a cool idea, but I don't know much about it.

Thanks again for sharing your discoveries in this area, it's valuable work you're doing.