[STRIPES-570] Document handling of forked repos in Stripes build Created: 15/Oct/18 Updated: 18/Nov/20 Resolved: 18/Nov/20 |
|
| Status: | Closed |
| Project: | Stripes |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None |
| Type: | Task | Priority: | P3 |
| Reporter: | Matthew Jones | Assignee: | Unassigned |
| Resolution: | Done | Votes: | 0 |
| Labels: | stripes_documentation | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Issue links: |
|
||||||||||||
| Sprint: | |||||||||||||
| Development Team: | Stripes Force | ||||||||||||
| Description |
|
As observed with folio/react-big-calendar and folio/react-githubish-mentions, forked third-party repos don't always play nice with our build process. This is because the forked repo likely has its own build and publish steps and should not be transpiled during a platform build of Stripes. (By default, all @folio-scoped modules will be transpiled using stripes-core's babel settings). A brief set of recommendations to review prior to introducing a fork would help. Notably we should ask ourselves:
Then provide guidelines on:
|
| Comments |
| Comment by Matthew Jones [ 15/Oct/18 ] |
|
After reviewing folio/react-githubish-mentions with John Malconian, it was noted that while this repo doesn't currently make use of "runScripts" to build, it does publish transpiled content. This is because a "prepublish" script exists to accomplish the task. The recommendation for runScripts over prepublish remains TBD. |
| Comment by John Coburn [ 17/Oct/18 ] |
|
The repos/projects themselves each potentially have their own way of dealing with this that conforms to whatever their needs are. To keep the delta on forks to a minimum, it's not ideal to require many changes to that aspect of a project for it to be set up for CI. OTOH a single prepublish key in the package.json is a pretty small change - it would just be an experiment to run and be sure it worked. My Jenkins-fu is weak - John Malconian if necessary, could commands for publish also specified in a Jenkinsfile? |
| Comment by John Malconian [ 18/Oct/18 ] |
Not sure I'm completely understanding the question. 'npm publish' is automatically run on the master branch or when the repo is git tagged and released. Outside of that, I don't think you want to run publish anywhere else. react-githubish-mentions currently has a prepublish script that invokes a 'build' script. This is totally fine, except that we probably want to invoke this build script in Jenkins for non-release/master branch builds as well. This can be accomplished by adding runScripts = [ 'build', ''] to the Jenkinsfile. Let me know if I'm missing something. |
| Comment by John Coburn [ 27/Oct/18 ] |
|
Exactly what I was curious about, thanks! We've seen some diversity among the ways that third party repos handle their publishing task, but nothing that seems like runScripts won't fix. Some are set up as simple as a 'prepublish' key in the package.json, and various other keys set accordingly to that setup (files, main, module, etc) others have build (or similar) commands that run series of tasks necessary to generate their published files. |
| Comment by John Coburn [ 18/Nov/20 ] |
|
Old story... the examples listed here are no longer in use. Closing! |