Serve application projects listed as project dependencies in /resources

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]

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.

[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