Replies: 3 comments 11 replies
-
Hi @HarelM, Thanks for the provided information. The use cases you shared I find similar to https://github.com/tradingview/lightweight-charts (the library I've maintained few years ago). Let me explain in more details. How it was done
The way it was implemented is the following. First thing - there is only 1 "real" entry point that actually exports/exposes everything that the library should expose. It is
Next, the library provides "a standalone" bundle (next to the esm one - you can check the output in "development" versions if you're interested) that has all dependencies bundled in and allows you to use it in playgrounds without any issues. This bundle is created based on a file That's it basically. So mapping to your options:
This looks clean for me, your library exports functions it needs, a user has control over what they want to have in their code. But unlike your library,
Alternatively, you can wrap all global functions into a namespace/object and export it with a name like The proposalAs for the proposal I'd suggest to make the following changes:
I think that's it. Hopefully I didn't miss anything 😂 Let me know what you think about it and let me know if you see any issues/problems or would like me to clarify anything. Some notes on
|
Beta Was this translation helpful? Give feedback.
-
Thanks for the detailed answer!
This extra complexity (which I'm not sure I fully understand I must admit) is expecting each chunk (that is represented by an entry point) to export a default variable. The code that gules everything: Which is all part of the rollup complicated config: When removing the default export in I think the main difference here between maplibre-gl and lightweight-charts is the worker code complexity (which is also the reason tree shaking is probably not possible, but this is besides the point). Any help would be appreciated. |
Beta Was this translation helpful? Give feedback.
-
@timocov one last question: |
Beta Was this translation helpful? Give feedback.
-
This is in continue to several discussions in issues in this project, mainly:
Map
collides with ourMap
object, I think... #287First and foremost, thank you for all the hard work put into this project, I don't want to sound ungrateful in any way, and if I come of in that way, please forgive me.
I'll see if I can describe the problem the way I see it.
The following is our public API generally:
https://github.com/maplibre/maplibre-gl-js/blob/bb219f0cc9046032b71fddc9fc59d10471bf97e3/src/index.ts
It's a bit long, let's look at how this API is begin used:
Option 1
The class is exported as part of the global window object and one can simply import the script and start using.
Our examples pages show this well:
https://maplibre.org/maplibre-gl-js/docs/examples/simple-map/
Option 2
Importing a global variable and using it, similar to the above example, but a bit more modern:
Option 3
The most modern one, import only what you need:
Another part worth mentioning are the global configurations, these are only available on the global object, for example the following code:
This is the gist of it, generally, and I simply want the generated
d.ts
file to allow that (maybe besides the first option) these kind of usages.I'm not sure I know how to change the public API to be different (modern?) and still facilitate for all this functionality.
Putting typescript aside, all this is working and I basically want dts-bundle-generator to understand what is being exported according to the index.ts file.
Side note: the bundling is complicated as we are using worker code and we are bundling the initialization of this worker code as part of this library, which might affect how index.ts is built and defined, and there's not a lot of room to play here.
I hope this gives a better picture, let me know if any of it is not clear.
Beta Was this translation helpful? Give feedback.
All reactions