[RFC] 0012 UI5 Tooling Extension API v3

[RandomByte]

Request for comment summarizing potential enhancements to APIs provided to UI5 Tooling extensions. Namely custom tasks and custom middleware.

View rendered version (main branch)

[vobu]

i like many -if not all- of the proposed enhancement! Also, introducing a breaking change w/ v3 is fine from my POV as providing backwards compatibility at that point would mean too much technical debt to maintain.

That being said, I'm somewhat torn on the ESM-only approach of providing the ui5 tooling modules themselves as this forces migration of all tasks and middlewares requiring any @ui5/* modules. The CJS/ESM split has caused enough uproar in the Node-community already and we shouldn't amplify this in UI5-land. Thus, I'd suggest to provide both ESM- and CJS-modules, similar to how fastify is doing it; and let the users decide on what to use.

What I'd like to also see is some improvement on bundling size - ui5 build all produces huge bundles that from my admittedly naïve POV could be shaken down significantly 😸

[mauriciolauffer]

I agree with @vobu , especially on the build comment. Today, "tree shaking" ignores sap.ui.core and shakes just other modules.

[mauriciolauffer]

I'd love to see the end of ui5 in package.json.

"ui5": { "dependencies": [ "no-more!" ] }

[RandomByte]

Thank you both for your feedback! Much appreciated!

@vobu: Our motivation to move to ESM mainly stems from the fact that many of our dependencies already made the move. This lead to situations where we struggled to consume security patches in dependencies. But we also like the concept in general, as well as the great interoperability with CommonJS. We think the Node.js ecosystem will move towards ESM more and more.

I'm somewhat torn on the ESM-only approach of providing the ui5 tooling modules themselves as this forces migration of all tasks and middlewares requiring any @ui5/* modules

We actually do not expect any great efforts for extensions that migrate to our v3 modules. When lifting the dependency, all they should need to do is replace for example require("@ui5/builder").xyz with await import("@ui5/builder/xyz"). There is no need to migrate the extension as a whole to ESM, thanks to dynamic imports being available in CommonJS too. Or is there something else that comes with this and causes concern for you?

Thus, I'd suggest to provide both ESM- and CJS-modules, similar to how fastify is doing it

Maybe Fastify is not the best example for our case, since the library itself is still written in CommonJS. It does not provide ES-modules in addition to CommonJS modules, but merely "ESM-syle" export of the same CommonJS modules.

When trying to require() our ES-modules on the other hand, Node.js will not allow this and throw an error. The only way to work around this, would be to transpile all relevant modules to CommonJS and ship both variants. Similar to how for example Yargs does it.

What I'd like to also see is some improvement on bundling size

That's still a major topic for us and many UI5 devs are looking into it. While it doesn't seem likely to get major improvements in UI5 Tooling v3, we got some related features like source maps for bundles and faster bundling in general.

I'd love to see the end of ui5 in package.json.

That's already part of the current v3 alpha release. If nobody faces any trouble during the beta, this will be reality soon 👍