SAP / open-ux-tools

Enable community collaboration to jointly promote and facilitate best in class tooling capabilities
Apache License 2.0
82 stars 33 forks source link

FEATURE - Using preview-middleware with cds-launchpad-plugin #2089

Open marianfoo opened 4 days ago

marianfoo commented 4 days ago

As a Developer, I want to use the preview-middleware to show the UI5 apps in a launchpad, so that I can see all UI5 Apps in a automatically created FLP.

Description

In my CAP projects, i use cap-launchpad-plugin to create a FLP with all UI5 Applications i defined in the CAP Project, without create manually a FLP html page. A similar approach like preview-middleware.

Technical Design

In the cap-launchpad-plugin we also have templates which will be filled the the necessary data at runtime (see code here). Ideally i would like to replace this with the preview-middleware. But when i look at the code, as this module is intended to be used a a ui5 tooling middleware, it is deeply connected to @ui5/server, but in CAP uses it own express server. I also can find a API like here are the all the options, return the complete html file. I think close to it is generateSandboxForEditor, but still missing configuration like all the apps data.

Acceptance Criteria

Given I have a API to create a FLP HTML Pages when I execute the cds-launchpad-plugin then a FLP Page will automatically created.

Notes

I don't know if this feature request is even in the scope of this module. I absolutely understand if the deep integration to the ui5 tooling should not be removed because there is a lot to refactor. Theoretically the cap-launchpad-plugin could use the ui5 tooling, but I don't know how to integrate it with CAP Server.

Even if the feature request is not implemented, an architecture help on how to proceed would be very nice! Generally the goal is to use your open source packages.

Cheers!

tobiasqueck commented 4 days ago

@marianfoo please check generatePreviewFiles in https://github.com/SAP/open-ux-tools/pull/2062. This might actually be what you need. We are adding these two new functions so that a user can "eject" a virtual file to the filesystem, however, we are returning a mem-fs-editor instance that you can also use to work with the files without writing it to the filesystem.

marianfoo commented 4 days ago

Thank you for your quick reply. I gave it a quick try, (https://github.com/geert-janklaps/cds-launchpad-plugin/pull/49/commits/0b5fa3c861a6179b86e0c36cdc99d5be2001766d ) but the method still expects a basePath to a UI5 application.

We may have one or multiple apps i collect here so i could provide paths for multiple apps. Is it possible to integrate multiple apps?

tobiasqueck commented 4 days ago

Ok, I get the problem now. I still like the feature. Let me get #2062 in first, and then think about this one as soon as time permits. We already have the option to support multiple apps, however, the assumption is always that one app is the root which is not the case here, so I need to think about how to cleanly do it in that case.

tobiasqueck commented 4 days ago

The multi app support that is support by the middleware was missing in the export and would be added with #2093, however, it still doesn't solve your problem because the middleware is written with one app under test in mind. You could create a dummy manifest in the mem-fs to solve your base path problem but it would result in a dummy tile in your flp sandbox.

@marianfoo the snippet below should create an FLP sandbox for two apps in folders app/[app-1|app-2] plus an additional dummy app.

import { create } from 'mem-fs-editor';
import { create as createStorage } from 'mem-fs';

const capRoot = '/my-capp-project';
const fs = create(createStorage());
fs.writeJSON(capRoot + '/webapp/manifest.json', { 'sap.sap' { id: 'dummy' }});

const config = {
    flp: {
        path: '/test/flpSandbox.thml',
        apps: [
            {
                local: 'app/app-1/webapp',
                target: '/app-1'
            },
            {
                local: 'app/app-2/webapp',
                target: '/app-2'
            }
        ]
    }
} satisfies MiddlewareConfig;
await generatePreviewFiles(capRoot, config, fs);

I am sure we could find a way to get rid of the dummy but i don't like the idea of pointing to folders with the sources. It would ignore @petermuessig cds-plugin-ui5, so I am not sure going down this route is a good idea.

tobiasqueck commented 4 days ago

I changed my mind. It wasn't that complicated. Please check https://github.com/SAP/open-ux-tools/blob/7ff4c63516a370a295c526e6e12eeeba5ddc58b3/packages/preview-middleware/test/unit/base/config.test.ts#L116-L139 (part of #2093). That should cover your case, and since you are responsible for hosting the files, it would also work with the cds-plugin-ui5 if configured correctly.