[Packaging] export addons (widgets and debug tools)

[mgermerie]

Context

Currently, widgets are exported within itowns bundle - in itowns/widgets. GuiTools are available as a single js file download within examples/js/GUI folder. Debug tools are not published and not suitable for use within an external project, as discussed in #2061.
There are also a few addons - some of which could get an update - available as a js file download in examples/js/plugins folder.

The packaging of these addons could be harmonized, making them available and simple to use in an external project. Meanwhile, the following addons would need to be rewritten/updated :

• [Refacor] rework plugins within examples/js/plugins folder #2201
• GuiTools, which could upgrade from dat.gui to lil-gui (used by three.js).
• debug tools whose code need some cleanup and which could also use lil-gui.

There is also the question of GitHub repository. We can either extract those addons to a separate repository in iTowns organization or keep them in iTowns/itowns repo. On this matter, three.js opted for the single repository option. It has the advantage of a simpler setup and maintenance.

These subjects are open to discussion.

Suggested solutions for packaging

Provided we opt for the single GitHub repository option, we could do as three.js addons :

• Gather them within an addons folder which could be at root level or in ./examples. The equivalent in three.js is the examples/jsm folder.
• Export them under an itowns/addons sub-package - as done here by three.js - or as a package of an @itowns npm organization we could create.

If we choose the separate GitHub repository approach, I don't know if we could still publish addons as an itowns sub-package, but we could still publish them as a package of @itowns npm organization.

[valentinMachado]

I rather the single Github repository option for the reasons you said. Theses packages/addons are going to be related each other it would be easier to maintain them if all modifications for a feature can be wrapped into one PR. CI can be done on all addons/packages.

I rather also the npm packages approach (in @itowns npm organization):

• dependencies update is handle with npm (and no copy paste)
• dependencies (external not @itowns one) are not part of the github repo (lighter)
• dependencies is more readable in the package.json
• dependencies between addons/packages is done with an id (name of the package) instead of a path

[jailln]

agree with you both and same opinion than @valentinMachado on the implementation for all the reasons you've both given