Assess yarn workspaces to handle multiple build configurations.

[subdavis]

Originally, I thought it would be easy enough to separate code by parent folder and just use aliases (As in #270) but I think some sort of multipackage organization will be needed.

Here's the packages we're going to have:

• vue-media-annotator library (published)
• viame-web application common (private)
• viame-web-girder web build configuration + API client (basically just API and a main.js file)
• viame-web-electron desktop build configuration, which will have a slew of other dependencies unique to the electron ecosystem.
• build-config a shared meta-package that has stuff like babel config, eslint config, jest config, all the stuff we'd have to duplicate across all other packages.

I've looked at how some other projects manage this, and they basically all ended up writing their own custom webpack to wrangle multiple build configurations. I think I'd rather have multiple packages and a single build config in each one.

I'm looking at something like https://medium.com/trabe/monorepo-setup-with-lerna-and-yarn-workspaces-5d747d7c0e91 but without lerna. Once Vue 3 launches, we're probably going to want to jump ship to vite, but I'm pretty sure using workspaces won't have any impact on that.

This will impact @mattrix27 as he explores electron. Requesting comments from @BryonLewis and @AlmightyYakob

[subdavis]

More research is clearly needed.

I also found https://github.com/nklayman/vue-cli-plugin-electron-builder

[BryonLewis]

Are you thinking viame-web is the surrounding "annotation Application" outside of the direct geoJS drawing and editing stuff with the track data management? Meaning things like the track list and type list interfaces?

Additionally I'm assuming the pipeline/training stuff falls into the viame-web-girder based on it's reliance of getting the data from server and utilizing the girder-worker?

Another assumption, the viame-web-girder package is meant to be interchangeable with whatever the electron stuff can provide for interfacing with the filesystem and the pipeline backend?

I don't know how on track I am here, but a final question is if we want to try to do this all at once or if we would want to try to do a a single section/package initially and then use what we learned for the other packages?

[subdavis]

Are you thinking viame-web is the surrounding "annotation Application" outside of the direct geoJS drawing and editing stuff with the track data management? Meaning things like the track list and type list interfaces?

I actually put track and type list into the library, but yeah that's the idea. UI that is specific to VIAME but common across web and desktop.

Additionally I'm assuming the pipeline/training stuff falls into the viame-web-girder based on it's reliance of getting the data from server and utilizing the girder-worker?

Well, the desktop app will need to run pipelines as well. I imagine the UI bits will be in the common package, and an interface that describes async functions to dispatch jobs and check the status of jobs will be in the common package, then we will implement that interface 2 different ways.

Another assumption, the viame-web-girder package is meant to be interchangeable with whatever the electron stuff can provide for interfacing with the filesystem and the pipeline backend?

Not sure I understand.

I don't know how on track I am here, but a final question is if we want to try to do this all at once or if we would want to try to do a a single section/package initially and then use what we learned for the other packages?

In order to verify that what we've done works, you sort of need to start out with a minimum of 2 packages. I was thinking we start with the library vue-media-annotator and everything else in viame-web. Then we can split the girder parts off and add a new package for electron stuff at our convenience.

Another assumption, the viame-web-girder package is meant to be interchangeable with whatever the electron stuff can provide for interfacing with the filesystem and the pipeline backend?

Not sure I understand.

What I mean is that ideally the data taken from viame-web-girder (like the location of images, the formatted track data) and the actions provided by viame-web-girder (saving annotation data, running pipelines) is going to be interchangeable with whatever we have electron do. The communication between viame-web-girder and viame-web should be very similar to the ones used for viame-web-electron. So these connections should be well defined which I think they mostly are right now. I.E. viame-web knows it need to save data, and hands it off, doesn't care whether it is saved to girder, or saved to the local filesystem.