Structure and handling of private modules

[Klaus-Keller]

We are expecting to have more private modules in this repository, e.g. for #1149, where multiple modules might be bundled into one.

The question is, where should we locate those modules or how to handle them. Currently, we have following modules marked as private: true in package.json

• Root package.json of this repo
• @sap-ux/types at /types
• the sample modules at /examples/* have set private: true in package.json

There are several options going forward:

1. giving up on our flat 1:1/folder:module-name structure under packages, which means creating sub-folders for modules belonging together
2. continue with the structure and having the private modules just mixed together with public modules
3. do not allow private modules and have all modules published
4. place all private modules in a separate folder
5. keep our current flat structure, use a certain scope for private modules, e.g. @sap-ux-private, and make sure the name is chosen so modules are name and directory-wise next to each other

We had a discussion with @devinea, @tobiasqueck @schreckstefan, consensus was to go with option 5. For consistency reasons this would mean, that we rename @sap-ux/types to @sap-ux-private/types and perhaps also root @sap-ux/open-ux-tools-root to @sap-ux-private/open-ux-tools-root. Samples might also be renamed.

FYI @voicis @kranthie-sap

Any other opinions?

[tobiasqueck]

I can't let the phrase "consensus was to go with option 5" be here without comment. While I don't mind if we go for it, I am not in full agreement that it is the best option. I am not arguing about the @sap-ux-private scope because it will make very clear it is private and also prevent an accidental publishing of the module, however, the flat structure is not my preferred choice because of the following reasons:

1. Right now, anyone can look at the packages in the repo and find a corresponding module on npmjs, so it is very easy to navigate between github and npmjs which is something I do often for other modules.
2. The two private modules in FEATURE - Enable control editing in adaptation #1149 are specifically designed for the one public module in FEATURE - Enable control editing in adaptation #1149 so they are not to be used by any other module in the repo - only the naming might indicate that

So, my preference is going for option 1 to solve the two listed problems. I'd recommend going for a fixed structure like the the public module has as subfolder subpackages containing a flat structure of all integrated private modules. That would make defining the workspaces straightforward. I would also use the @sap-ux-private scope from option 5.

So, again, this is my preference for the reasons above BUT I am ok with option 5

[tobiasqueck]

There is also an option 6 which is being implemented in #1166. For this implementation, the team is facing the same problem as in #1149, some parts of the code need to be transpiled differently. Option 1-5 would all be an option there as well, but it was decided to keep everything in one module but defined sub-folders in src with different tsconfigs and build scripts that are executed in sequence with pnpm build.
The initial setup was tricky but now it seems to run smoothly, so an alternative option 6 is not having private modules but keeping everything for one module in one module.

@voicis @Jimmy-Joseph19 maybe you could comment why option 6 is not a good idea for #1149

[voicis]

Regarding Control Property Editor, we had a react app and code that needs to be injected in UI5 app initially in the same package, because it required less set up initially and seemed more convenient. However, working on it over time the set up proved less than ideal.

1. Even after quite a lot of effort and trying to juggle a lot of tsconfig files, we didn't get to a point where the compiler, Typescript language server and ESLint was working as desired. It would seem to be working fine for a while and then you'd get some strange inconsistencies between build and editor or linter.
2. While having separate folders for in theory should be enough to indicate that code is running in different environment and prevent from adding undesired coupling between components, however in practice this was not always the case. Perhaps this could be mitigated with ESLint rules that warn about problematic imports, but I'm not sure if would cover everything.

Having separate packages makes the separation between the modules clearer and also makes configuration simpler, which I think is important for maintainability.

While currently they these modules would only used by one module they are structured in a way that they can be reused. It doesn't cost us much (in mono repo to have) them as separate modules. If there is a need for reuse in the future then it would also save us the trouble of extracting the code from a single package.

[devinea]

I don't like option 6 for the reasons outlined above.

[tobiasqueck]

Agree, option 6 would just remove the "problem" of having private modules but otherwise not be beneficial.

I also like @voicis's point about the ease of moving the module within the monorepo, so as long as the modules are private we can move them around, delete them etc. without impacting anyone outside. Having this in mind, I would reiterate my preference for keeping these two private modules coming with #1149 somewhere nested under the public package that includes them (until we have another need for them) to only make them "visible" when looking at the public module. Nevertheless, I understand that @devinea and @Klaus-Keller prefer keeping everything flat in packages and I am also ok with that.

@voicis what is your preference btw?

[voicis]

I don't have a strong opinion on flat vs nested structure as long the module names have the same prefixes, so they appear next to each other in the file system.

[Klaus-Keller]

@tobiasqueck, the assumption here was, that we are expecting more private modules. If private modules can be avoided, I'm all for it. I'm not really in favor of private modules that are used by one module only. If the same could be achieved with a structure within one module, like done in #1166, I would prefer this.

Having that said, I'd still change the scope of existing (and reused) private module @sap-ux/types and the sample modules that are private.

[tobiasqueck]

After a little tinkering and a few discussions, we agreed that ideally we do not want private modules, however, if needed for valid reasons then they can be added. It is required to use the @sap-ux-private scope.

The first private module that was introduced with #1261 is the preview-middleware-client containing client sources required by the `preview-middleware. The reasoning here:

• they are still a few expected changes for this module and we only want to consider publishing it once these are in
• these client-side sources must not be used by any other UI5 application, therefore, publishing it would create an unnecessary risk