How to use in external projects itowns debugging tools ?

[valentinMachado]

In our project ud-viz we need debugging tools, and particularly 3DTiles. We have developed a DebugTool but itowns has dedicated debugging tools. Sounds like we are doing the same thing twice (wasting resources to maintain our code + we cannot contribute to itowns ones).

The problem is that itowns does not expose its debugging tools as they are though to be use only in itowns project.
I tried to export a transpiled version of utils/debug/Main.js in package.json but the code transpiled is pointing to src folder... I tried then to bundle it and then use it directly in html but its require to have itowns as global variable (+ dat.GUI)...
Easiest solution could be to do the same way as widgets.
Another could be to do a separate npm package dedicated.

This imply to:

• debug depend on dat.Gui module, which is imported in html we should use its npm package version
• if we are doing a separate package itowns should be a peerDep

Note: I also tried when ud-viz was pointing to itowns folder locally to webpack directly pointing to the src but our webpack cant pack glsl files.

What's your opinion on this ?

[jailln]

I totally agree with your observation as we also need debug (3D Tiles) tools. My opinion is that we should publish it as a separate npm package (and I think we should do the same for widgets but this is another topic ^^).
What's your opinion @valentinMachado @mgermerie @ftoromanoff @gchoqueux ?

[valentinMachado]

Yes. Let's publish one package for the debug tools (btw we already publish a static bundle here).

I've tried to use this bundle but it needs that itowns is a global variable as dat.GUI

[mgermerie]

Yes. Let's publish one package for the debug tools (btw we already publish a static bundle here).

I think the debug tools should stay in the same repo though, WDYT? Regarding extracting the widgets in a second repository I have second thoughts since it would be easier to test the widgets every time we modify itowns core if we keep them in the same repository... WDYT? If we keep everything in the same repo, I think we should still reorganize a bit like this:

src/
widgets/
debug/

Perhaps debug tools as well as GUITools could be re-factorized within a specific (or several) widget(s). I guess a tool to switch visibility properties (like opacity etc) of layers is relevant as a widget and the same goes for a tool to display debug information IMO. What do you think about it ?

[mgermerie]

Actually in ud-viz we were confronted to the same problematic (ie separate our code in different packages) we have choosen the mono repo approach (mono repo vs multi repo). Base on other mono repo like these ones (1 , 2, 3). The good approach looks like to organize the packages code like so:

itowns-root-github-folder
|__docs
|__test
|__packages (folder containing npm packages)
|   |__core (or framework or whatever) <== current itowns package
|   |__widgets
|   |__debug
|__ ...
|__package.json (npm package of the mono repo)

The npm package at the root of the mono repo is a private package meaning is not meant to be published but it's here to automate some scripts + factorized dev dependencies needed in the mono repo context + take advantage of the workspaces property of the package.json.

Another aspect to consider is to switch itowns from a npm package to an organization this allow more or less to publish scoped packages which would looks like this @itowns/package_name which is not necessary since packages can be name itowns-package_name but imo is more elegant.

EDIT: Hum sounds a bit overreact to just import dat.GUI... if itowns in the future is going to add packages (which depends on other npm packages) this approach is the right one to scale. But if this is not the case and debug + widgets are and will be the only "packages" needed. Then we should consider to do like three.js write javascript code in a separate folder of the src and expose these files in package.json if this javascript code depends on another lib (here dat.GUI) this lib should be present in this folder as a bundle (that will guaranted versioning stuff and make "standalone code" for itowns user)

I admit I'm not fully familiar with the pros and cons of the mono repo approach vs the multi-repo one. I'll take a look at the info you sent to try to get a better understanding.

[jailln]

I like the proposition with the monorepo approach and the different packages @itowns/core @itowns/widgets (and maybe @itowns/widget-minimap, @itowns/widget-scale, etc. also) and I think it is clearer and easier to use than the threejs way of doing it. And I think it would be a good idea to refactor the debug tools as widgets.

[gchoqueux]

Split itowns by features groups is good way, we would this structure for a long time. The structuring could go by group of specialized functions @itowns/core @itowns/widgets @itowns/VectorTile @itowns/3DTiles.

It's important to create a good interface and documentation to simplify the creation of external packages (like plugins)

[EricBoix]

Is anything scheduled for the realization of this matter ? Because it doesn't seem to be part on the roadmap.

[jailln]

It has not been planed yet. You can also check the items we plan to work on for [the next version]https://github.com/orgs/iTowns/projects/3) contains the items for the next version (scheduled soon). It is updated for the following version at each release. There is also a Roadmap project but it (sadly) does not yet contains all the items we plan to work on and it is not updated regularly enough yet too. We have to improve that.

Would you be interested to participate in the implementation of this issue?