Closed garrettjstevens closed 4 years ago
Is there a particular problem with the inter-package dependency on linear genome view that is a problem?
For packages that use jbrequire()
, anything that gets imported has to first be exported from ReExport.js
, which is in core. This would mean that core would depend on certain plugins (like LinearGenomeView), which is probably not ideal.
So, one article of faith I'd like to promote is that we don't want our future plugin registry to have to track inter-plugin dependencies. That would get crazy really quickly.
For core plugins, them depending on each other has the effect that they can't be rolled into products independently, which is not great, not terrible.
One thing I'd hope we can keep is a certain composability of classes from different plugins. Oftentimes this has been achieved in jbrowse 1 by actually calling "const CLASS = require(config.someClass); const adapter = new CLASS(...)" where config.someClass could be from a plugin's class or a core jbrowse class class. If the only thing that can be jbrequired are core things, we may lose this composability(?)
Seems like we have at least some general understanding of this now? There is a bit of interpackage dependency in core plugins, which we could track more, but maybe that could also be reduced over time. Maybe close for now
Yeah I concur we can probably close for now
On Sat, Aug 8, 2020 at 9:39 PM Colin Diesh notifications@github.com wrote:
Seems like we have at least some general understanding of this now? There is a bit of interpackage dependency in core plugins, which we could track more, but maybe that could also be reduced over time. Maybe close for now
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/GMOD/jbrowse-components/issues/627#issuecomment-671005437, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAASAFLPMXL45YHKSFXPW3TR7YSAPANCNFSM4JKLHDWA .
Ya, I guess there could be a discussion about how to be more strict about inter-package dependencies in our core plugins that is a little bit more refined than this question
One specific example we have currently is that
@gmod/jbrowse-plugin-linear-genome-view
package exportsBaseTrack
,blockBasedTrackModel
,BlockBasedTrack
,basicTrackConfigSchemaFactory
, andbasicTrackStateModelFactory
, which are imported by any package that has a track.Easiest thing to do is to put those all in core and say no inter-package dependencies are allowed, but it also means if someone else developed some track primitives for their plugins, they'd have to include them separately in every plugin.