You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thanks for this simple yet powerful package, it's a great idea and still gets the job done after these years! I'm wondering if there's any plans for releases in the near future?
For context, build tooling around ECMAScript modules has really matured the past couple of years (thanks to projects like Vite) and shows no signs of slowing. This is great for the long-term health of the JS ecosystem.
Would you accept a PR which basically generates a proper ESM build? This would let the code be properly statically analysable by rollup and similar build tools, allowing them to treeshake and minify the code as small as possible.
It's not like react-tracking takes up a lot of space, but when you host on CF workers with a 1mb bundle size limit, every kb counts...
I can't say exactly what needs to be changed yet. Just that I can see that using react-tracking causes prop-types and hoist-non-react-statics, as well as the entirety of react-tracking's source code (e.g. the HoC & decorators code which I never use), to be included in my final bundle.
If you're open to this, could also be an opportunity to replace prop-types with TS, maybe remove the HoC & decorator functions (don't think it's a common pattern anymore) and ship a major breaking update?
The text was updated successfully, but these errors were encountered:
Thanks for this simple yet powerful package, it's a great idea and still gets the job done after these years! I'm wondering if there's any plans for releases in the near future?
For context, build tooling around ECMAScript modules has really matured the past couple of years (thanks to projects like Vite) and shows no signs of slowing. This is great for the long-term health of the JS ecosystem.
Would you accept a PR which basically generates a proper ESM build? This would let the code be properly statically analysable by rollup and similar build tools, allowing them to treeshake and minify the code as small as possible.
It's not like react-tracking takes up a lot of space, but when you host on CF workers with a 1mb bundle size limit, every kb counts...
I can't say exactly what needs to be changed yet. Just that I can see that using react-tracking causes
prop-types
andhoist-non-react-statics
, as well as the entirety of react-tracking's source code (e.g. the HoC & decorators code which I never use), to be included in my final bundle.If you're open to this, could also be an opportunity to replace prop-types with TS, maybe remove the HoC & decorator functions (don't think it's a common pattern anymore) and ship a major breaking update?
The text was updated successfully, but these errors were encountered: