New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
v3 Roadmap #275
Comments
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 Examples:
|
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:
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. |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
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 :) |
Breaking features
.d.ts
from importing Webpack (handled by pkgroll)sourcemap
option in favor of Webpack'sdevtool
optiondefault
for auto inference based on file pathESBuildMinifyPlugin
toESBuildPlugin
(because it can be used as a transformer too)plugin.ts
ESBuildPlugin#format
toiife
if target isweb
(as per bug: minifier used to transpile pollutes global scope with helper methods #139)tsconfig.json
detection/loading viaget-tsconfig
include
/exclude
/files
in tsconfigtsconfig
property on loader to accept tsconfig pathesbuild as a peer dependencyTracked in https://github.com/privatenumber/esbuild-loader/tree/next #306
Please feel free to share any more breaking change ideas
The text was updated successfully, but these errors were encountered: