Open jbibal-pdc opened 4 months ago
@jbibal-pdc Sorry for my late reply - the idea is great - I'm just thinking how to do it - would be a .dotenv
file or environmental variables OK to control the apps to be started as a comma separated list with the NPM package names? WDYT?
Hi @petermuessig, thanks for replying and considering my suggestion. Yes, maybe a .dotenv
file or an environment variable.
Personally, I was also trying to think of a good way to handle it as part of this feature request but couldn't think of a cleaner implementation.
While awaiting a response though, I did play around with it on my local and added support for a custom config in package.json
in the form of pkgJson.cds?.["cds-plugin-ui5"]?.includeModulesOnly
.
Like if this setting is true
, then only those with a specified config under the pkgJson.cds?.["cds-plugin-ui5"]?.modules
is included during testing, specifically, during the time the localApps
array is populated.
Something like:
const includeModulesOnly = pkgJson.cds?.["cds-plugin-ui5"]?.includeModulesOnly || false;
// Then during the LOCAL apps iteration
if (!skipLocalApps) {
const appDir = path.join(cwd, cds?.env?.folders?.app || "app");
if (fs.existsSync(appDir)) {
// is the UI5 app directly in the app directory?
if (!fs.existsSync(path.join(appDir, determineUI5Yaml(appDir)))) {
// lookup all dirs inside the root app directory for
// being either a local app or a UI5 application
fs.readdirSync(appDir, {
withFileTypes: true
})
.filter((f) => f.isDirectory())
.forEach((d) => {
// Do a check here for the custom flag
if (includeModulesOnly && !includedApps.includes(d.name)) {
return;
}
localApps.add(d.name)
});
localApps.forEach((e) => {
const d = path.join(appDir, e);
if (fs.existsSync(path.join(d, determineUI5Yaml(d)))) {
localApps.delete(e);
appDirs.push(d);
}
});
}
}
}
I mean it's not the best idea. Haha. I just thought of trying something to reduce local testing run times.
Hoping other developers could chime in.
@jbibal-pdc thanks for your suggestion, and sorry for not providing a fix yet - still thinking about the best option, but maybe we could change the plugin to startup the middlewares on demand (means in case of the first request happens to the application), this would then only start the middlewares which are really necessary for the execution. For a development scenario, this should be fully sufficient. And for sure, we can also add an immediate start-up option to the config... WDYT?
Is your feature request related to a problem? Please describe. When using the plugin with a big project, with multiple Fiori / UI5 apps, running the CAP / CDS server becomes very slow as it needs to spawn a server for each of the apps, when there are times that we only want to test and work on a particular app.
Describe the solution you'd like Probably a config wherein we can specify which apps to include or maybe exclude when starting the server.
Describe alternatives you've considered Break down the apps into different projects, which is a hassle since the apps share the same domain models.
Additional context