Option to disable tree-shaking

tnfAngel commented 8 months ago

Sometimes you want to bundle unused types in the code, for example for a shared project library with common types.

timocov commented 8 months ago

Why would you need this and why don't you use the standard compile declaration generation in this case?

timocov commented 8 months ago

I mean, if you have a shared project with common types, just use generate declarations with tsc and declaration: true and use them? Why would you need to bundle them in this case? The purpose of this tool and bundling in general is to bundle only code you use and discard one you don't use. If you know that you need everything, you can export it from the entry point and the tool will handle it (re-exporting everything from every module). Or you generate types with declaration: true by running tsc and that's it.

tnfAngel commented 8 months ago

I mean, if you have a shared project with common types, just use generate declarations with tsc and declaration: true and use them? Why would you need to bundle them in this case? The purpose of this tool and bundling in general is to bundle only code you use and discard one you don't use. If you know that you need everything, you can export it from the entry point and the tool will handle it (re-exporting everything from every module). Or you generate types with declaration: true by running tsc and that's it.

tsc is not going to generate a bundle, the point of the bundle is to have everything in a single file, not just to eliminate the parts that are not used (yes, it is also part of it but it is not the final objective). If it's easy to do, an option will be great to be added, but if not, that's fine.

timocov commented 7 months ago

the point of the bundle is to have everything in a single file

@tnfAngel That's right, but "everything" starts with an entry point(s). If there is a type that is not used anywhere which means that it is not even exported from that bundle, what's the point of including it if you won't be able to import it?

On a side note, how do you bundle your js code for this type of bundles? Is there any specific configuration that lets you achieve this (e.g. include functions you don't use into result bundle)?

If it's easy to do, an option will be great to be added, but if not, that's fine.

Well first of all I want to understand this feature more why this might be the case. Without this understanding, even if it is one-line change, I will not merge it, because the tool should do what makes sense for many people, not just for one very specific use-case.

tnfAngel commented 7 months ago

the point of the bundle is to have everything in a single file

@tnfAngel That's right, but "everything" starts with an entry point(s). If there is a type that is not used anywhere which means that it is not even exported from that bundle, what's the point of including it if you won't be able to import it?

On a side note, how do you bundle your js code for this type of bundles? Is there any specific configuration that lets you achieve this (e.g. include functions you don't use into result bundle)?

If it's easy to do, an option will be great to be added, but if not, that's fine.

Well first of all I want to understand this feature more why this might be the case. Without this understanding, even if it is one-line change, I will not merge it, because the tool should do what makes sense for many people, not just for one very specific use-case.

i'm using bun build (the native bundler for bun) with the plugin wobsoriano/bun-plugin-dts, this plugin uses this project. It works great but it's tree shaking my unused types. These types are exported (even when exported they are deleted) and will be used, but not within the library itself (which uses the plugin to bundle), but will be used by the users of the library itself. So tree-shaking is not convenient in this case.

timocov commented 7 months ago

So tree-shaking is not convenient in this case.

Tree-shaking operates on exported types in the first place, if a type is exported from the entry point, it must not be removed from the output.

These types are exported (even when exported they are deleted)

@tnfAngel So you're saying there is a potential bug in there - explicitly exported types must not be removed because of tree-shaking. Can you provide a repro?

tnfAngel commented 7 months ago

i'll switch again to the plugin and see

tnfAngel commented 7 months ago

https://github.com/FNLB-Project/Pragmatic/commit/e3e7672f0eb0896997122088df7c267594660798

It just generates this (what it actually used inside the lib), and not even on the entrypoint folders imagen