I assume you will have to deal with such categories of files:
CS- shared code
CC- common code
FS- shared configuration
FC- common configuration
DS- shared data
DC- common data
my hypothetic folder structure (lets assume windows) would look like this:
in /src I would have git clones for main branch of project and every shared submodule. Eventual changes in client forks/clones would be merged/rebased here. This main git repo would keep releases of your app.
in /dev I would have git branches for every client with shared code as git submodules.
in /data/common I would keep all common data (files, images, sqlite databases etc.)
in /data/client[xx] I would keep only specific client data.
In /conf/common I would keep shared configuration ie app parameters, server data etc.
In /conf/client[xx] I would keep specific client parameters - smtp passwords, ssh, this client app conf etc.
In /dist/client[xx] I would keep the result of quasar build and other files copied after distribution command (environment, statics). The files from this folder should go to server or be a source for continuous integration/delivery.
in /bin I would have build/dev/dist tools for every client:
this tool is for developer. depending on dev model it could take code and data from git, it could properly build configuration/environment data, npm/yarn and of course run “quasar dev -m spa” command in proper client directory.
this tool should run a command “quasar build” and the client project will be compiled into proper /dist/client[xx]. then there will be copied there specific client configuration files and data files - and of course - common data and common configuration
this tool should distribute your app to production in whatever means necessary
Whats in /dev/client[xx]?
This is a quasar project, with .gitignored specific .env file, with highly modified quasar.conf.js. In /dev/client[xx]/src there are git submodules with shared code. The modifications to quasar.conf should take parameters from client[xx]_dev.cmd and client[xx]_build.cmd and act accordingly. For example it could take a path to configuration files and prepare this clients .env file or put some data into build.env quasar.conf.js section. It is also possible to use custom webpack configuration here and just copy some common or shared client files during the dist phase.
Well, thats the gist. The main pain point with this workflow is of course git management, but I doubt that with such specific assumptions of client separation/multi tenancy, any other solution would be less painful.