Serve application projects listed as project dependencies in /resources

[BenReim]

Expected Behavior

In some use cases, it is desired to use multiple ui5 components in a shared environment (for instance loading an application component appB file during runtime once a tile was clicked in appA). This is currently possible with HTML5 / ui5 applications that are deployed in a SCP account, in conjunction with a configuration in neon-app.json.

Current Behavior

As of now, ui5 application projects won’t be served in /resources when running ui5 serve in a ui5 root project, even when they contain an ui5.yaml descriptor file and are listed as dependencies.

Steps to reproduce the issue

Suppose the following structure of two ui5 application projects:

my-root-app/
    \_ node_modules/
    \_ webapp/
    \_ ui5.yaml
    \_ package.json

openui5-sample-app
    \_ node_modules/
    \_ webapp/
    \_ ui5.yaml
    \_ package.json

A global link of the openui5-sample app is created:

cd openui5-sample-app
npm link 

The sample app is added as a dependency

cd my-root-app
npm link openui5-sample-app
npm install 

The ui5-sample-app is made known in the root project:

	<script id="sap-ui-bootstrap" type="text/javascript"
		src="resources/sap-ui-core.js"
		data-sap-ui-theme="sap_belize"
		data-sap-ui-libs="sap.m"
		data-sap-ui-bindingSyntax="complex"
		data-sap-ui-compatVersion="edge"
		data-sap-ui-preload="async"
		data-sap-ui-resourceroots='{
			"my.app": "./",
			"sap.ui.demo.todo": "/resources/sap/ui/demo/todo"
		}'>
	</script>

However, when running ui5 serve in my-root-app, requests that point to the openui5-sample-app will fail.

[RandomByte]

Instead of enhancing the application type, @matz3 and I discussed the possibility of adding "component" types which are always served at their namespace (e.g. /resources/my/todo/app).

Application projects would then only act as an entry point or test environment (e.g. the OpenUI5 testsuite, which is actually not a UI5 application) and will continue to be served at / and enforced to be at the root of a dependency tree that contains an application project.

This setup would be closer to how many apps are being developed, especially in the Fiori Launchpad context.

CC @codeworrior @petermuessig

[sebbi08]

hi Currently we are doing a workaround with defining the Project as shim

---
specVersion: "1.0"
kind: extension
type: project-shim
metadata:
    name: openui5-sample-app
shims:
    configurations:
        "openui5-sample-app": # name as defined in package.json
            specVersion: "1.0"
            type: module # Use module type
            metadata:
                name: "openui5-sample-app"
            resources:
                configuration:
                    paths:
                        /resources/open/ui5/sample/: "webapp"

this comes with the problem that the shims in the sub project are not applyed corrertly

they are applyed but on root level an not the level of the subproject

so following shim inside the openui5-sample-app

---
specVersion: "1.0"
kind: extension
type: project-shim
metadata:
    name: moment
shims:
    configurations:
        "moment": # name as defined in package.json
            specVersion: "1.0"
            type: module # Use module type
            metadata:
                name: "moment"
            resources:
                configuration:
                    paths:
                        /lib/moment/: "min"

will result in the following scructur

root
├── /resources/open/ui5/sample/
│                        └── lib <- dose not exist
└──/lib/moment <- shim of shim is inside the root folder

[RandomByte]

@sebbi08 The virtual path defined for a module project is always absolute. Also see this documentation.

To get the expected behavior, your shim would need to define the virtual path as /resources/open/ui5/sample/lib/moment.

Namespaces, "root paths" or other hierarchy-like attributes are not shared between a project and its dependencies (even if they are shimmed).

[resitamas]

Hi @RandomByte , do you plan to add the "component" types in the near future? #45 (comment) Do we have any other solution for this issue? Thanks

[RandomByte]

Hey @resitamas, this is one of many topics we are currently pursuing. So I can't give you an ETA. However we see great demand in such a type.

Currently we are in discussion on how such a "component" project should be structured. I.e. whether it should look like the current "application" projects (one "webapp" directory, containing a "test" directory) or more like the current "library" projects with separate "src" and "test" directories and a deep directory hierarchy representing the projects namespace. We tend towards something in between, like a flat hierarchy (without the namespace) with separate "src" and "test" directories.

[attila-boros]

Hi @RandomByte, this would be very helpful for a local "mock launchpad", hosting multiple applications and testing cross navigation locally.

From: https://sap.github.io/ui5-tooling/pages/Builder/#types

Projects of type application are typically the main or root project. In a projects dependency tree, there should only be one project of type application. If multiple are found, those further away from the root are ignored.

I'm wondering if it would be possible for those further away from the root to be served under their namespace.

[zdravko-georgiev]

Hi @RandomByte, Hi @matz3, will this also support a monorepo project structure? E.g. I have a monorepo with multiple apps, then I can execute ui5 serve in the root of the monorepo and are able to preview all the applications contained in the monorepo.

[BenReim]

Hi @RandomByte, is it considered to add the component type feature as part of a tooling v4 release?

[matz3]

Hi @RandomByte, is it considered to add the component type feature as part of a tooling v4 release?

It is unfortunately out of scope for the initial 4.0 release, but as long as it doesn't require breaking changes it might come in a later 4.x minor version.