[FOLIO-1570] Identify release procedure for folio/react-big-calendar in CI Created: 10/Oct/18 Updated: 12/Nov/18 Resolved: 22/Oct/18 |
|
| Status: | Closed |
| Project: | FOLIO |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None |
| Type: | Task | Priority: | P3 |
| Reporter: | Matthew Jones | Assignee: | Matthew Jones |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Issue links: |
|
||||||||||||||||||||
| Sprint: | |||||||||||||||||||||
| Description |
|
It is currently not possible to include @folio/react-big-calendar at the tip of master within a platform build without build errors. This complicates release of platform-complete or any other platform that includes ui-calendar. As a fork of a project, it appears folio/react-big-calendar may require its own release procedure. For example, master contains a babel config defining a plugin not present in our webpack config. Looking at currently released artifacts on npm-folio, these babel settings are not included. This leads me to believe the project requires some pre-transpilation before publishing a release and including it within a FOLIO platform. Normally we include @folio-scoped modules in the transpilation process since we author the source. However, we do have logic in our build process to exclude specific folio-scoped modules that should not be transpiled. My guess is folio/react-big-calendar should be added to this list. However, we will need to know the proper process to publish this module to both npm-folio and npm-folioci. Update: As discussed during yesterday's (Oct.18) Stripes call, it was noted the upstream react-big-calendar project has changes which would alleviate the current publishing issues. Notably, the package.json's "main" entry points to the generated "lib/index.js" and the "files" array includes all of /lib. "main": "lib/index.js", "files": [ "lib/", "LICENSE", "README.md", "CHANGELOG.md" ], Merging the latest would help with the current publishing issue, however, also introduces the need to review other upstream changes depending on how much our fork has diverged. |
| Comments |
| Comment by Matthew Jones [ 10/Oct/18 ] |
|
István Bender, I'm hoping you can provide some assistance with this one. Is there a procedure for releasing this to npm-folio and npm-folioci for our platform builds? Please correct me if any of my assumptions in the description about needing to pre-transpile this project are incorrect. |
| Comment by Matthew Jones [ 15/Oct/18 ] |
|
Looking at folio/react-big-calendar, it seems we need some combination of build and/or release package scripts to get this done. "build": "yarn run clean && babel src --out-dir lib && yarn run assets && yarn run less", "release": "release", Running the build script generates a whole /lib of transpiled content. Looking at existing published artifacts, there is no lib folder because our Jenkins isn't running build. John Malconian notes that we could use our Jenkinsfile to invoke other scripts in addition to our normal CI routine. runScripts = [ 'build' ] Even with the /lib directory, the package.json main points to /src/index.js which is not transpiled. Interestingly the files array of package.json references /src and /lib/css (but not /lib). "files": [
"src/",
"lib/css",
"LICENSE",
"README.md",
"CHANGELOG.md"
]
István Bender can please you comment? It appears you prepared the previous release. I'm curious what your steps were. Open questions: If the answer to the second question is yes, then we would have to account for this project's .babelrc configuration during our build. If the answer is no, then we simply add this to our folio-scope exclusions. I'd prefer to rely on the transpiled artifacts if possible. |
| Comment by Matthew Jones [ 15/Oct/18 ] |
|
Also in chatting with John Coburn, this may represent a more general issue in that any forked repo could come with its own build and publish steps. Ideally we have a way to instruct Jenkins on this and runScripts is probably the solution. A document/guide/recommendation on what to review when introducing a third-party fork into our CI would help. Created
|
| Comment by Matthew Jones [ 22/Oct/18 ] |
|
I'm marking this complete with respect to identifying a solution with runScripts, finding the publishing changes in the upstream repo, and including folio/react-big-calendar in the exclusion list preventing it from being transpiled during the webpack build (https://github.com/folio-org/stripes-core/pull/468). However, there still is work remaining to merge the latest upstream changes into folio/react-big-calendar so the transpiled code is properly generated and referenced. This is outlined in
|