ui5-tooling
ui5-tooling copied to clipboard
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.
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
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
@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).
Hi @RandomByte , do you plan to add the "component" types in the near future? https://github.com/SAP/ui5-tooling/issues/45#issuecomment-416236542 Do we have any other solution for this issue? Thanks
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.
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.
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.