Disable tree shaking

[DreamTexX]

Hey, is it possible to prevent the transformer from removing "unnessecary" imports from typescript when transforming it to javascript?

[kdy1]

Are you using swc from js, there's no api to do so.

[kdy1]

You can use swc.print but I don't think it will be performant enough.

[DreamTexX]

Well i currently parse it to get all imports, than i transform it and the I add the imports back into the new ast... so it propably would be much more efficient than the current... the simplest solution would be to add an option do disable tree shaking or something like this

[kwonoj]

Would you mind try suggested approach first and see if it works? For now, it's little bit hard to determine if this feature is something frequent that core api surface need to support as public for long run.

[DreamTexX]

Well i've tried, eighter i do something wrong or it doesn work, but when i load the script with swc.parse and the print it with swc.print it just keep the typings (even when targeting ecmascript). So i switched to parsing it first and getting the import nodes that must be kept, than i transform the code with swc.transform, then i parse the transformed code again and check if the desired imports are present. If not i add them and swc.print the stuff again. This is way to complicated, and i don't really see the point of not adding it to the api as it does not bother anyone who does not need it. If it is already a present feature in the crates i don't get why not publishing it, but rather forcing me to use an inefficient workaround.

[kwonoj]

I don't think I'm in position to make a decision solely, but in my opnion to support / expand api surface, I think there's firm need with frequent usecases. Having public api surface to opt in obviously won't hurt any user, but in terms of core team's maintanence we have to keep up across semver, reason I mentioned bit hard to determine if this feature is something frequent that core api surface needs.

To double clarify, I'm not trying to say either we shouldn't or should support this. Also I don't represent whole core team's opinoin. It is my personal opinion it may need some actual usecases to be part of public api surface.