[RFC] 0001 Type Extensibility

[RandomByte]

A feature to customize how a specific UI5 project is being built.

CC: @tommyvinhlam @matz3

[RandomByte]

a63033f: Removed build phases as discussed today between @matz3, @tommyvinhlam, @codeworrior, @RandomByte

Build phases would allow for more precise extensibility of a types build execution. Mainly scenarios where only a single task should be replaced or added could overwrite one of the build phases to hook in-between of certain sets of tasks.

Instead, they will have to overwrite the whole build function containing all tasks. The main reason for this decision is the lack of known extensibility use-cases. Therefore we do not want to decide on the naming and semantics of any build phases yet as changing them later on will hardly be possible.

[themasch]

As suggested in https://github.com/SAP/ui5-builder/issues/32 I'd like to add thoughts about this topic in the mix.

(Disclaimer: this is a lot of text and I'd like to say sorry for that. I'm not good at being brief.)

I really like the idea of being able to extend and "personalize" the whole build process to be able to tweak the tooling to a project's needs and those of its developers.
But I'm not yet sure if replacing the whole build process with a custom one is really what I want to do all the time. I'm kind of wearing my "composition over inheritance"-Fanboy-Shirt on this topic. But maybe we are talking about total different use cases so I guess I'll just explain mine and someone tells me where I'm wrong ;)

I experimented with the use of babel to translate modern es6/esnext syntax to something even the poor little IE11 can understand. When working on a UI5 application I can run the application from source in chrome, even run the test in chrome (manually or using karma) and iterate quickly while doing tests on the compiled/bundled versions of the application on demand or even as late as on the CI.

Our toolchain (described in a gruntfile) looks something like this

  [src]        [build]              
  babel ---,-> openui5_preload -,-> [dist] -- nwabap-ui5uploader / npm publish --> target
  copy  --´    copy_debug -----´|
  copy_static------------------´

With the ui5-tooling I could replace the gruntfile with just the ui5.yml and get 4 / 6 steps from just that (+ a lot of cool new things the grunt setup cannot do, like standalone builds).
The only bits missing are deployment and babel.
While deployment might be out of scope for the ui5-tooling it is currently kind of hard to work around the lack of Babel. I guess it would be possible to use grunt to babelify & copy the assets to a build dir and launch ui5-build on that, but that requires another task runner to be involved what kind of defeats the idea.

I currently think that my "ideal version of reality" would look something like this:
When I want my assets to be compiled with babel before building the preloads I just install a "@ui5/babel-plugin" from npm and make a configuration in my ui5.yml that says "build_plugins: [ 'babel' ]" or something like that.

The babel-plugin is then loaded when setting up the build and is able to hook into the build process on clearly defined interfaces. Since the whole idea of the ui5-tooling (as I understand it) is to be an "opinionated tool runner" purposed for ui5 application/library/extension development there is no need to allow the configuration of bells and whistles. Destination and source directory and pretty much set in stone.

Coming back to the actual PR after this short journey, to solve this problem with a type extension I'd need to define a new 'babel-compiled-application', extend the base application in a class and inject babel in that pipeline. If I want to build a library using babel as a transpiler I'd need to do the same thing for a 'babel-compiled-library'.
Let's say I want to use scss on some of these projects as well, so I need to extend my babel-compiled-something to a "babel-compiled-something-with-scss-support".

Very long story short: While I like to be able to extend and configure everything, I'm not sure if that's the best way to allow a configurable build process. I'd like to be able to build a process by picking add-ons/plugins over having to replace the whole thing. But I may have misunderstood the purpose of this PR.

[cschuff]

@themasch

I'd like to be able to build a process by picking add-ons/plugins over having to replace the whole thing.

I'm totally with you on that.

I'd like to see ui5-tooling as a set of functions/tasks that I can stick together and run however I want with placing additional stuff before, after or right in the middle of it. That is why I prefer gulp over grunt a lot.

[RandomByte]

In our internal discussions, one of the most controversial topics is whether the UI5 Tooling shall have characteristics of a task runner or that of a collection of tasks.

Personally I don't want to build another task runner here. There are plenty of those out there. However, with the CLI and Types we kind of already built one. So I have to agree that it makes sense for people to customize and enhance what ui5 build does to a project.

The main questions I would like to get clarified as a starter here are:

• What defines the execution order of a types tasks?
• And how can a project inject one or more additional tasks into that?

I'll add my ideas once I can think of something simpler than an enormous configuration architecture like Maven and others have 😑

[RandomByte]

We discussed this again internally and would like to go forward with a simpler approach very similar to the proposal of @themasch.

RFC 0004 Simple Build Extensibility

Please have a read. Any feedback on the concept is appreciated.

Also, thank you @themasch and @cschuff for your feedback so far!