bug: .js extension added to a sub-dependency after bundling - Githubissues

favware / esbuild-plugin-file-path-extensions

An esbuild plugin to automatically insert file extensions in your built JavaScript files based on the specified target

MIT License

17 stars 1 forks source link

bug: .js extension added to a sub-dependency after bundling #113

Open KaisSalha opened 1 month ago

KaisSalha commented 1 month ago

Is there an existing issue for this?

[X] I have searched the existing issues

Description of the bug

The dependency matcher works after bundling is done, this fails because subdependencies aren't matched.

https://github.com/KaisSalha/esbuild-plugin-file-path-extensions-bug/blob/76f3f4a4fdc5fc6fc0c0def14b738b1335d538f6/dist/index.js#L15265

I can look into this some time later, but I'll busy for a while.

Steps To Reproduce

https://github.com/KaisSalha/esbuild-plugin-file-path-extensions-bug/tree/with-fix

Expected behavior

Have it work without bundling? Have it run before bundling? Rethink dependency matcher?

Screenshots

No response

Additional context

No response

favna commented 1 month ago

Man... this hole just keeps getting bigger and bigger doesn't it :(

Here I was trying to make a cool extension to output files in a library so they can be subpath imported as well as cross compiled for CJS and ESM (for example it's used in https://github.com/sapphiredev/utilities/tree/main/packages/utilities) but then this plugin became more and more popular and now there's lot of edge cases to account for. Not that I mind the rising popularity, on the contrary, but it's still a bother for all users.

As for a way to fix it, maybe instead of just scanning package.json the code should recursively scan all subdependencies?