Feature request: Add package.json for each application in the project about generator-ui5-project

[tobiasqueck]

From my perspective, it would help to better separate the apps from each other, so I am all in. If anything is required in the open-ux-tools, just let me know.

[nicoschoenteich]

I generally like the idea. I do think we would need to touch code in quite a few different places, but I guess it's feasible. I know that @petermuessig also has an opinion on this as we talked about the whole uimodule-structure a while ago.

[petermuessig]

IMO, a mono-repo setup requires a package.json for each module. We should in general rework the structure. In case of including ui projects and backend project the dependencies are rather different and must not be mixed. Ideally the project also uses a mono repo tool such as yarn or better pnpm. We should follow-up on this after the summer holiday break. In general, we should think about streamlining the generators more in depth - at least the ones coming from the UI5 community.

[Klaus-Keller]

With PR #42 @tobiasqueck introduce support for SAP Fiori elements Flexible Programming Model (FPM) pages and also added question:

? Do you want the module to be visible in the SAP Fiori tools? (Y/n)

Could we work on a PR to apply the new monorepo structure in case this questions is answered with Yes, only. Like a frontrunner implementation, because we need this for SAP Fiori tools. If the new structure finds acceptance, we could also use it as default for other generated project.

[tobiasqueck]

I like the strategy, however, it might be technically a bit more complicated to do it this way because you need two implementations for multiple sub-generators (I assume).

[Klaus-Keller]

I' ve prepared a sample mono repo that has two Fiori apps. One FPM enabled app, similar to the one generated in this script: https://github.com/tobiasqueck/ui5con2022, generated with yo (generator-ui5-project) and one Fiori elements List Report Object Page v4 app, generated with @sap/generator-fiori. While generating both apps I've choosen all available linting and JavaScript helper options.

Here is the repo: https://github.com/Klaus-Keller/fiori-monorepo

What I've done so far can be seen in the commit history (bottom to top). Of course, looking at the details there are some open questions about what to move to the root and what should be kept on app level, but in general I think this sample could serve as a basis for discussion. We could add more and different apps to it to see how they related.

[tobiasqueck]

Do we want to limit it to pnpm or should the generator offer to generate for yarn, pnpm or npm@7+?
Where would you put the btp deployment script e.g. mta.yaml etc.; would this be another (private) module in packages?

[Klaus-Keller]

Hi @tobiasqueck,

Do we want to limit it to pnpm or should the generator offer to generate for yarn, pnpm or npm@7+?

I'd start with pnpm and if there is a community demand for other package managers, it should be a rather simple contribution to add support for other package managers.

Where would you put the btp deployment script e.g. mta.yaml etc.; would this be another (private) module in packages?

Good question and this is exactly the kind of discussion I like to have. I guess this depends on your scenario, if you have modules that are all deployed together it might be on root level, if you selectively deploy certain packages you might want to go with a private module in packages.

Other things, especially devDependencies, that we need to discuss include:

• linting rules; I assume in most cases you want to have one ruleset for all apps in your monorepo
• UI5 version specific modules; like @sap/ux-specification or @sapui5/ts-types. If all modules in your monorepo are deployed to the same target, they might share the same UI5 version. Otherwise, if apps need different versions of UI5 specific modules, they can't be defined on root level devDependencies.
• tooling support; modules like @ui5/cli or @sap/ux-ui5-tooling are good candidates to consolidate to root.
• testing; also highly dependent on the actual scenario, I'd propose to keep it on app level, open for discussion.

[nicoschoenteich]

The monorepo approach has been implemented and merged with PR #75