Why export threejs and proj4js ?

[jailln]

Why does itowns export its own copies of threejs and proj4js ?

[gchoqueux]

In html file, if you use the bundle file itowns.js, you don't need to import the bundles three.js or proj4.js.
Otherwise if a user would import a three bundle there would be two instances of three.

In the case of a module, three and proj4 aren't exported.

An alternative would be to use dependOn to force the import of bundles three.js or proj4.js.

[jailln]

Some packaging systems (e.g. google closure) use static files to import dependencies. Therefore I think we should also produce a bundle file itowns.js without three.js and proj4.js and rename the actual bundle to something indicating that it also packages its peer-dependencies. That would leave itowns users the liberty to choose which bundle is more suited. WDYT ?

[gchoqueux]

Some packaging systems (e.g. google closure) use static files to import dependencies.

is different than the webpack dependency system (with dependOn option) ?

Therefore I think we should also produce a bundle file itowns.js withouy three.js and proj4.js and rename the actual bundle to something indicating that it also packages its peer-dependencies.

is it the size of the bundle that motivates the generation of two different bundles ?

[jailln]

is different than the webpack dependency system (with dependOn option) ?

As I understand it, the dependOn option would be another way to export libs (e.g. threejs, proj4js) in itowns bundle, but with webpack. Is this correct or do I miss something on what it does?

Google closure dependencies management system just exports modules and imports others somewhere else in the code. Also, it has no central repository where packages are downloaded from. My point was that even if threejs and proj4 are not exported when importing itowns as a module, some projects may still use the bundle to import itowns because they use other dependency systems than npm and they may not want to import threejs and proj4 along with itowns.

is it the size of the bundle that motivates the generation of two different bundles ?

Well actually this is another discussion that I wanted to open so it is related but not limited to :) The main motivation is that I want to import iTowns in a project that already has its own copies of threejs and proj4js. Therefore I end up with two copies of threejs and proj4. A solution would be to remove threejs and proj4 copies and use those of itowns but I was thinking that allowing to import itowns etiher with or without its peer dependencies would give more freedom to users.

[gchoqueux]

dependOn splits bundle, if you use dependOn with three.js with itowns entry then all three code is removed from itowns bundle.
So three bundle must be loaded before this entry point is loaded.

<script src="three.js"></script>
<script src="itowns.js"></script>

for the rest, we have to talk about it 📞

[jailln]

I tried to use dependOn but I didn't manage to make it work. The documentation is not detailed and there isn't much examples. If you or anyone has any experience with webpack and/or dependOn, I would be happy to discuss it.

Some other elements that we discussed on the phone / that I tested on my end for the record:

• this choice has been made so one don't need to import threejs and proj4 bundles when importing itowns bundle in an html page (which is the main usage of itowns bundle).

• threejs and proj4 declare global variables so you cannot have two copies of them in your project (even if you don't want to have two copies of a library in your project anyway in general)

• not exporting three and proj4 with itowns only reduces the size of the bundle from 2.1Mo to 2Mo and one has to import them again if one needs other methods from these libs.

• the npm itowns module does not contain three nor proj4 since they are declared as peer-dependencies in the package.json, so one must add them as dependencies of its npm project when importing itowns has a module.

• Having the same process with the bundle by using dependOn is a good lead for developpers that need to import itowns as a bundle in their project.

• Regarding the bundle size, I tried tree shaking but it didn't change the size, so either I did it wrong, or it is already done ?

• An analysis of the bundle with webpack-bundle-analyzer shows that the size of itowns mainly come from some of its dependencies that are used in itowns and cannot be removed and from itowns code itself:
  

• Maybe we could discuss providing more modular packages (e.g. itowns/core, itowns/3d-tiles, itowns/mvt, etc.) but I think this subject is worth openning another discussion :)

[gchoqueux]

Maybe we could discuss providing more modular packages (e.g. itowns/core, itowns/3d-tiles, itowns/mvt, etc.) but I think this subject is worth openning another discussion :)

yes, this is the idea we want to put in place

[jailln]

After an offline discussion, we found out that the technical solution is using webpack externals. Adding three and proj4 as externals reduces the size of itowns bundle from 2.1Mo to 1.4Mo. However, the right version of these modules need to be imported before itowns bundle and one must use three and proj4 from these imported version and not the versions exported by itowns (i.e.. replace all itowns.THREE. by THREE. and itowns.proj4 by proj4.). This would have an impact on: users that import itowns with its bundle, itowns examples and itowns deployment on itowns-project website.

Regarding users that import itowns with its bundle, I think we cannot do much more than saying that this is a breaking change and explain the changes needed in their code (those detailed above, which are quite limited). In addition, I don't think many people import itowns from the bundle, except for small applications / examples.

Regarding the two other impacts, I see two possible solutions:

• import three and proj4 from node modules in itowns examples:

<script src="../node_modules/three/build/three.min.js"></script>
<script src="../node_modules/proj4/dist/proj4.js"></script>

Copy these two files on the server hosting itowns-project during the deployment.

• import three and proj4 from CDNs (e.g. https://cdn.skypack.dev/[email protected] and https://cdnjs.com/libraries/proj4js/2.7.5). No changes for itowns-project deployment in this case. To avoid changing all examples each time we upgrade three and proj4, we could store the versions as a global variable used in all examples.

Personally, I like the second option more. In addition, I think externalizing itowns peer dependencies from the bundle would be beneficial because it splits it in multiple parts (better loading performances); it is more flexible to use; projects using it explicitly import three and proj4 which is clearer on their side.

What's your opinion on this ?

[jailln]

Any news on this ?
Also, OpenLayer has a similar usage of proj4 than iTowns but only has it as a dev dependency; Maybe we should take this as a model ? What would be the implications of having it as a dev dependency ?

[jailln]

Up :) @gchoqueux what do you think ?