Upgrade esbuild-loader and @craco/craco
Versions were way behind causing issues for our project, alle the examples seem to be working using these versions.
Modified the EsbuildPlugin import as mentioned in the esbuild-loader migration docs and removed the typescript check as the esbuild-loader now does that automatically (See 3.0.0)
Added a requirement for node 16 matching esbuild-loader requirements v3
@Crecket thanks for the pr, it seems that the tests are broken with the new changes, can you please have a look?
for the tests, we should probably stop supporting node 16 as it's not LTS anymore and move the ci to run on node 18 + 20
Removing the loader means it will check for jsx/tsx file extensions to decide which one to use and it was failing on JSX content without a .jsx extension in the example. It does seem nice to let the esbuild-loader handle that behavior over this plugin checking for a tsconfig but I guess we could revert that change and not touch the old behavior as I imagine this would break existing apps and force people to use .jsx over regular .js extensions in their projects
Changed the default node version to 20 for the release step / swapped to running only node 16/18/20 for the tests
Besides that, I upgraded some other dependencies to fix the builds and added a missing babel dependency that was breaking the typescript example for some reason.
@Crecket I think the tests are failing because you are using pnpm 8+ and the ci is using pnpm 6 so the generated lockfile is incompatible.
Any chance we can get this in soon? I was looking to open a PR but found that it's something that's in the doing already.
I'd also suggest to keep esbuild-loader as a peer dependency - it makes it easier for users of this plugin to control the version they wish to use
I'll look into this again this weekend, been away/busy for a bit so haven't had time to fix the last few issues yet
I see CI is passing now, any chance it can get approved? @pradel
Published in 0.6.0