Plugin stop going deeper to translate the re-export from the other packages

[Jelda Lam]

Hi, thanks for this plugin. It help our project a lot in reduce file requests. But I notice the process of auto translate the import URL is just support the first level, when the imported package is exporting the other package's components from the same workspace it not going forward to process.

For example:

// module.ts import { a, b} from 'packageA'; import { c } from 'packageA';

// packageA/index.ts export { a } from './a'; export { b } from './b'; export { c } from 'packageB';

// packageB/index.ts export { c } from './c';

component a and b import statement is perfect translated to:
import { a } from 'packageA/a';
import { b } from 'packageA/b';

but component c is not being able to do the same, it translated to:
import { c } from 'packageB/index';

It would be nice if the plugin can handle this case, it will bring the flexibility in more use cases.

[n028]

Hey! Thanks a lot for your suggestion, I'm pretty sure there is room for improvement on this matter, I'll look into it! 👍

However, please keep in mind that in the end - based on your example scenario - it would probably still require you to also manually set packageB as an entry point in the targets plugin option (right now doing that would result in an error because of packageB/index.ts being cleaned up).

I would not want this plugin to end up crawling through one's entire project just to resolve circular dependencies on its own., it could eventually become counterproductive. I'd rather have users know their projects and explicitly state which module(s) should be tree-shaken. Hopefully this makes sense, please let me know :-)

[Jelda Lam]

Hi, thank you for the response.

Manually setting the targets is definitely the right approach here. I had already tried this before reaching out (of course, it didn't work). Therefore, I believe it's a good idea to let the project owner decide which packages need to be tree-shaken, rather than having the plugin auto detect it. It is also good for performance.

[n028]

I've just released v.0.3.0 which should address your issue. Please let me know and feel free to re-open in case it did not work. I've also added your scenario as an example.

[Jelda Lam]

Hi, thanks for very quick fix.

Although when I try install the new version, I got this error

Command "unbuild" not found

I notice that the root package.json now have two new line of scripts

"postinstall": "pnpm build",
"build": "pnpm unbuild",

[n028]

Woops, postinstall is in the core package, when it should be in the root, sorry for that, fixing it.

Hotfix available (v0.3.1), hopefully I did not miss anything else too obvious because I have to go right now 😅

[Jelda Lam]

Thanks, the patch worked. However, there's a minor issue:

When attempting to use export * from 'xxx', an error occurs: [plugin:vite-plugin-entry-shaking] end is out of bounds. In the previous version, the entire 'xxx' module would be loaded instead.

[n028]

Thanks for the valuable tests and feedback @jeldalam, appreciated! I've just opened a PR addressing this issue, so this should probably be fixed once I release v0.3.2. I'll probably release it soon enough as I feel like this is not just a minor issue and quite annoying. I would like to investigate a bit further possible edge cases and issues introduced by the feature too, so additional patches may be expected!