Feature request: Add package.json for each application in the project

[Klaus-Keller]

Easy-Ui5 version:

Run yo easy-ui5 --plugins to print all relevant version strings

generator-easy-ui5: 3.5.0

When I generate a project using generator-ui5-project, I get a file and folder structure like following

com.myorg.myUI5App
    ├── karma-ci.conf.js
    ├── karma.conf.js
    ├── node_modules
    ├── package-lock.json
    ├── package.json
    ├── readme.md
    ├── tsconfig.json
    └── uimodule
        ├── ui5-mock.yaml
        ├── ui5.yaml
        └── webapp

The actual UI5 application resides in uimodule, where the ui5.yaml config and webapp directory is. This project structure suggests, that there might be other apps in the same project. However, with multiple apps in the same project, the root package.json would be shared. This might lead to unwanted behavior as in some situations, different applications have different devDependencies, dependencies, or scripts. To overcome this inflexibility, I propose to slightly change the generated structure of projects to include a package.json for each application in the project. This would enable the flexibility we know from monorepos, common dependencies are hoisted to the root of the project, but we still have the flexibility to have dependencies per app.

We could also consider generating all apps into a new directory packages, which is commonly used for monorepos (but not necessarily required).

The resulting project structure could look like this

com.myorg.myUI5App
    ├── karma-ci.conf.js
    ├── karma.conf.js
    ├── node_modules (hoisted)
    ├── package-lock.json
    ├── package.json
    ├── readme.md
    ├── tsconfig.json
    └── packages
        ├── uimoduleA
        |   ├── node_modules (from ui module A)
        |   ├── package.json
        |   ├── ui5-mock.yaml
        |   ├── ui5.yaml
        |   └── webapp
        └── uimoduleB
            ├── node_modules (from ui module B)
            ├── package.json
            ├── ui5-mock.yaml
            ├── ui5.yaml
            └── webapp

As we from SAP Fiori tools organization receive requests to support monorepos, we could help in preparing the code for such a structure into generator-ui5-project

@tobiasqueck @petermuessig @nicogeburek @lboehm @vobu what do you think?

[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 https://github.com/ui5-community/generator-ui5-project/pull/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 https://github.com/ui5-community/generator-ui5-project/pull/75