Plugins ?

[mbredif]

I do not know if this issue implies documentation or development, but what is the standard way of adding custom functionalities to itowns ?
In other words, simple projects may only rely on js code in the html page but more more complex project (custom providers, custom materials...) may require to tweak the internals of itowns. Is it required to then fork the project or is there some kind of plugin architecture ?

[autra]

Ideally we should not have to fork the project.

As Oslandia, we often do that for client projects. My current process is:

• install itowns as npm dependency npm install itowns --save
• use whatever bundler (webpack, rollup...) to import individual itowns module into your files.
• create your own module. You can very well create your own material, own provider (and execute view.mainLoop.scheduler.addProtocolProvider etc... A lot of things are already possible, but of course we might miss some API. Don't hesitate to open issues or PR for them!

The process is quite similar as to using THREE in your project. Just use itowns in your project the way we use THREE in itowns... Well I would say that if our package wasn't currently broken !

Indeed, I just realized this morning (while you were writing this probably) that things are a bit funky these times:

• if you want to use three, you should use itowns.THREE and not three directly. It's because we should declare THREE as a peerDependency instead. I'm fixing this asap.
• Our npm package is currently broken because THREE.MeshLine - one of our dependencies - doesn't declare THREE neither as peerDependency nor as dependency... So sadly it works on itowns because we directly depend on THREE, but not on project that depends on itowns. I expect the above point to fix that as well.
• project that depends on itowns and import it via a package bundler MUST declare a global __DEBUG__ var somewhere. I need to fix that too. They won't have this problem if they use the bundles in dist/.

[autra]

BTw the package is broken in 2.1, not in 2.0 (we don't use MeshLine there).

[autra]

@mbredif FYI:

• Remove debug code from transpiled sources. #531 fixes the last problem
• Fix npm package #532 the first.

For the problem with MeshLine, one workaround is to install three in your client with npm install --save three, even if you don't use it.

I'll try to push a client example on our organization to get you started.

So again, ideally, client code won't need to fork itowns or copy the bundles into their repo, but will use it as any npm dependency.

[mbredif]

That is great, thanks for the comments and the fixes !
Is this process of using itowns as an npm dependency documented somewhere, maybe as a tutorial ?
It would help a lot to get people on board !

[autra]

Yes briefly in the README. But frankly, this is a "web project with npm and a module bundler tutorial" that you want. There will be nothing specific to itowns in this process. Again, the best example is how we use THREE.js in itowns.

Nonetheless, I'll try to push my "itowns client bootstrap" when I'll have time.

[ilokhat]

"project that depends on itowns and import it via a package bundler MUST declare a global DEBUG var somewhere. I need to fix that too. They won't have this problem if they use the bundles in dist/"

hello @autra
this is not yet fixed !
i had to add "DEBUG ==false" to make it work

[autra]

@ilokhat yes, it is fixed in master, but not yet published to npm. You'll have to wait for next release. I hope to do it soon.

[ilokhat]

nice,
thanks !

[gchoqueux]

Since #798, it's more to add and use new Parser (to parse file and converting to Feature) with all Layers (ColorLayer, ElevationLayer, GeometryLayer)

[zarov]

@mbredif knowing the current simpler architecture of iTowns, if it is enough complete for you concerning this issue, I let you closing it.

[gchoqueux]

There's the question to build iTowns plugins as npm packages.