It takes longer to use the latest version
chaoranwill opened this issue · 12 comments
When I upgraded from version 4.0.1 to latest, it took significantly longer time to build
I tested each version again and when I upgraded from version 4.0.3 to version 4.1.0-0, the time spent increasing. And I noticed that you added support for prettier in this version. Is this caused by this reason? Will it be optimized?
Prettier is only a development thing - it doesn't affect build times. The one thing that has changed between those versions is this commit - 22f1b81 - and this, in theory, might lead to longer build times. I haven't noticed it to be a problem though, what are the times (in your case) we are talking about?
Oh, Yes, you are right. It not caused by prettier. I found that it is caused by the commit "Fix preflightChecks for ignored files".
@Andarist . Thank you very much for your reply. When I use the previous version, it takes 37 seconds to generate the product using rollup, but now it takes 45 seconds. Since there is a significant increase in time-consuming, are there other optimization options, such as using the original method for some directories, such as node_modules.
Merging this #292 would allow you to use skipBabelHelpersCheck (or similar). I don't have much time to finish this PR though
@Andarist I found another problem. The judgment condition of the following code seems to be not rigorous, because the return value in _classCallCheck is also included, resulting in unnecessary repeated execution of the transform function. Is this a mistake or I am wrong?
if (~check.indexOf('class ')) { check = transformSync(inputCode, addBabelPlugin(options, fallbackClassTransform)).code; }
function _classCallCheck(instance, Constructor) { if (!(instance instanceof Constructor)) { throw new TypeError(\"Cannot call a class as a function\"); } }
Do you mean that the check fails because of the resulting output containing that error string which has "class " in it?
Sorry, I got it wrong, please ignore the above question. But I still don't know what kind of problem you are trying to solve by changing preflightChecks. If I continue to use the previous version, what kind of scenario will there be a problem? Thanks again 🙏
Not sure what do you mean, preflightChecks are supposed to catch developers misconfiguring this plugin. I don't want to change them, just want to provide a way to disable them entirely for power users who don't want to waste time on them and who are sure they know how to configure things without this plugin verifying it.
I found the answer here #16 . I understand that this is done to avoid ignoring the local .babelrc file. If I set babelrc: false and customize the configuration file, the change of preflightCheck have no effect on my project. Am I correct?
Still not sure if we are on the same page. At the moment (with current v4) preflightCheck is just something that happens within this plugin and is not something you can disable or configure in any way.
The preflightCheck gives us information about how your babel is configured for a certain file and that information is used to determine if rollup-plugin-babel has been configured correctly with externalHelpers/runtimeHelpers/inlineHelpers options.
With 5.0.0-alpha.1 (soon to be released as a stable version - just need to migrate this plugin to Rollup plugins monorepo and update docs) you can disable those preflight checks by passing skipPreflightCheck: false to the plugin.
I believe this addresses your issue so I think this can be closed now. If you still have any other issues - please just open a new one.