[ui5-tooling-modules] ui5-tooling-modules-middleware should respect addToNamespace option

[mgerzabek]

When developing a custom control in typescript that makes use of a recent version of d3 I realized that the ui5-tooling-modules-middleware server middleware is not able to replace d3 version 3.4.12, which is shipped with openui5 out of the box.

In looking for a possible solutions or workaround I stumbled upon this issue where I posted my concerns.

Thankfully @codeworrior provided a solution that works well when developing.

I post his answer here:

ui5-tooling-modules-middleware and ui5-tooling-modules-task differ in respect to the addToNamespace option. While the task honors it, the middleware seems to keep the native NPM names (check the -dbg source for your chart without using source maps).

You can work around this by removing UI5's mapping of the d3 name:

sap.ui.loader.config({
  map: {
    "*": {
      "d3": null
    }
  }
});

This must be done before any eager dependency to d3 is requested. I only managed to achieve this by adding this config to the HTML page.

But it IMO would be better if the middleware would also use addToNamespace.

When packaging the library the correct version from package.json is included as thirdparty lib due to the addToNamespace option in ui5.yaml.

BUT, consumers of this custom library also have to employ the loader trick to make the loader aware of the custom d3 thirdparty library in their dev server.

May I propose to enhance the ui5-tooling-modules-middleware to respect the addToNamespace option for easier consumption of included libraries in openui5?

Would be a great enhancement for an already great tool!

[petermuessig]

@mgerzabek - thanks for the feedback, I will also take this topic for a discussion with @codeworrior

We in general discussed a similar topic already recently - so this also fits quite good into the discussion...

[mgerzabek]

That's good news @petermuessig!

In a prefect world there would be a specific loader for each thirdparty ui5 library in dependencies of package.json – not the sap/open/ui5 ones…

But I'm not sure if this is possible with JS/TS. Java has this concept of scoping a class loader. Maybe that approach could be feasible for loading libraries?