A common UI5 project structure puts all important stuff related to app itself inside webapp folder. But we have an unsung warrior on WebIDE templates called SAP Fiori Launchpad Plugin that doesn’t follow that pattern and makes root directory as its homeland. There is no pain deploying from WebIDE, but this kind of project structure have some flaws that bitters your activities.
- Ugly project layout: plugin artifacts are side-by with with non-related deployment files. Risk of deploying more files than needed.
- Not very CI friendly, at least I didn’t had success with it:
- Gruntfile: doesn’t create a dist folder and scatters preload files on root dir. Cherry-pick files to deploy is a no-effin-go.
- UI5 Tooling: won’t build at all. Changing webapp path to ‘.’ (root folder) on YAML file makes it try to preload all node_modules files and that doesn’t ends well. Maybe adding node_modules to exclusion could work but adding rules to fix tooling issues is not a good way to solve them.
This blog is a follow up to my question, some time tinkering about it and I realized something about this project layout: it can be improved. I took that route and both builders started to work as it should. I adopted the same structure as any other common UI5 project: webapp as our code folder.
It’s silly simple that it shouldn’t worth a post. Steps are way shorter than this briefing but I’m still here writing it. Let’s go!
- Create webapp folder (that was easy).
- Move i18n folder, Component.js and manifest.json to webapp folder.
- Edit fioriSandboxConfig.json, appending “webapp/” to url parameter. This way the Launchpad Simulator will know where to find plugin files.
- Optional (but almost mandatory): for some reason i18n model is not registered on manifest.json. Do it now or regret later.
You did it! You can build with UI5 Tooling using default YAML without hiccups and leverage CD pipelines.
Autobuilds, roll out!