11 11 2020 Meeting

Meeting Minutes > 11/11/2020 Meeting

Agenda Topics

Updates to Framework & Repository
- Switch to 100% JavaScript dependencies
  - No longer any OS-specific dependencies like bash or command prompt to make MySQL calls
  - We only have to maintain JavaScript moving forward (yay!)
- Framework Roadmap page ( https://github.com/aldefouw/redcap_cypress/wiki/Framework-Roadmap )
Vanderbilt Support
- Meeting with Rob Taylor
- Plans moving forward

Adam De Fouw met virtually with Rob Taylor on October 26, 2020 regarding the implementation of UUIDs into REDCap Source
Adam has been granted access into REDCap core source repository and can add the UUIDs to a branch
Anyone else from our committee who wants to help can also request access to help
Chris Chapman & Adam De Fouw talked about implementation Pros / Cons of UUID vs. Cypress tags
Overall, it seems like UUIDs are the route to go on the basis of their flexibility and ease of implementation

Chris Chapman and Adam De Fouw discussed how we might version the library moving forward. Vanderbilt uses semantic versioning (i.e. major.minor.patch) ... but the question is, can we do the same for our library? Should our versioning mirror Vanderbilt's somehow? Let's think some more about this and what it would mean.
Chris Chapman and Adam De Fouw also discussed whether it might be appropriate to make this repository into its own NPM package. Adam mentioned that he has considered doing that, but versioning would need to be figured out first. He has worked on other libraries and they can quickly become a dependency nightmare if not planned out well. Adam also mentioned that when you go down the package route, you need to make sure you stick to semantic versioning because breaking changes need to end up in a new major version release.

Do we have the resources available to support a shift like that?

Develop a strategy and ultimately a guide for implementing UUIDs into REDCap source code so that anyone can do it who works on the core tests
Determine what Versioning strategy we should use on this repository. It is appropriate to package the library as its own NPM package?
- This would hide away a lot of the complexity of Cypress that is currently present
- Would (potentially) reduce the customization ability for institution specific tests (although not if carefully implemented)
- Something to be thinking about as move forward with the library