[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:
Blocks
blocks FOLIO-1549 Upgrade platform-complete to stripes 1.0 Closed
Relates
relates to STRIPES-570 Document handling of forked repos in ... Closed
relates to UICAL-46 Update folio/react-big-calendar Closed
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:
(1) What build artifacts do we need to publish for folio/react-big-calendar?
(2) Do we need to transpile folio/react-big-calendar when building a platform?

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 STRIPES-570 Closed

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 UICAL-46 Closed and continues to block FOLIO-1549 Closed .

Generated at Thu Feb 08 23:14:19 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.