Breaking features

• [ ] esbuild as a peer dependency
• [ ] tsconfig.json detection/loading via get-tsconfig
• [ ] Bundle distribution files https://github.com/privatenumber/esbuild-loader/pull/265
• [ ] Move to https://github.com/esbuild-kit/ org
• [ ] Increase supported Node.js to v16

Please feel free to share any more breaking change ideas

Just ran into an issue where jsx wasn't being transformed correctly due to the nearest tsconfig.json relying on extends to load in the compilerOptions.jsx rule. It looks like using get-tsconfig would solve this issue since it resolves extends.

Just curious, what would make swapping to get-tsconfig a breaking change?

The implementation for tsconfig.json detection/loading is quite off so I thought it would be a breaking change for anyone relying on that behavior. Alternatively, it could be unexpected if it suddenly picked up some configuration it previously wasn't reading.

Examples:

• The config file resolver joycon traverses up the directory to find a tsconfig.json. TypeScript doesn't really do that. It should just check the current directory or accept a tsconfig path.
• tsconfig.json is loaded via JSON5, which supports more features than just JSONC

Ah, thanks for the explanation. Happy to help with some PRs if you want :)

Debating whether to move esbuild from dependency to peer-dependency.

The main argument for making it a peer-dependency is that it makes it easier to specify which version of esbuild to use. However, I think that's easily possible even with esbuild as a dependency using any of these methods:

1. Using npm update to upgrade nested dependencies within the semver range
2. Using overrides if you want to upgrade to a version outside the semver range
3. Passing it in via implementation option

The second argument is that it would remove the responsibility for me to update esbuild-loader every time esbuild releases a new major. But since I would set the peer-dependency to a semver range I confirmed works, I would still need to cut a new release to update the semver range.

I'm not sure if there are actually any benefits to having it as a peer-dependency.

I also don't want to needlessly complicate installation/setup by asking users to install esbuild and esbuild-loader. Webpack has a very wide range of users (different eng levels, languages, etc.) so I would like to keep it as simple as possible.

Do we have a plan to support dynamic import?

It's always been supported. Test case: https://github.com/privatenumber/esbuild-loader/blob/ecb181ed98b0b61769c038c01745e7884a733c1b/tests/specs/loader.ts#L386

---

Please refrain from asking about features here. This thread is for breaking changes.

Debating whether to move esbuild from dependency to peer-dependency.

The main argument for making it a peer-dependency is that it makes it easier to specify which version of esbuild to use. However, I think that's easily possible even with esbuild as a dependency using any of these methods:

The second argument is that it would remove the responsibility for me to update esbuild-loader every time esbuild releases a new major. But since I would set the peer-dependency to a semver range I confirmed works, I would still need to cut a new release to update the semver range.

I'm not sure if there are actually any benefits to having it as a peer-dependency.

I also don't want to needlessly complicate installation/setup by asking users to install esbuild and esbuild-loader. Webpack has a very wide range of users (different eng levels, languages, etc.) so I would like to keep it as simple as possible.

I'm happy to see that you opted to not make ESBuild a peer dependency, I find that annoying more than anything else and it overcomplicates installation especially when users are expected to install WebPack only and not care about ESBuild itself, the beauty of this loader is that it uses ESBuild behind the scene and nothing is required by the user to take advantage of ESBuild except for the small webpack config change. I also dislike peer dependency when they are added on open source project that eventually no longer have support and are eventually throwing npm install errors because they have fixed peer dependency on say Angular 10 even if it works fine with 15. I doubt that would be the case here because of the switch to sebuild-kit but still, I'm happier without peer deps ;)

Thanks for this great loader, I definitely use it in my case because I have to stick with WebPack because of the project complexity so this loader is great for that use case :)