Fix StatoscopeWebpackPlugin import to support default export #357
Conversation
The import of StatoscopeWebpackPlugin was adjusted to use the default export, which is necessary when the module exports a single class or function as the default. This change ensures that the plugin is correctly instantiated whether the `why` flag is used or not, and it resolves issues that may arise if the module is not exporting an object with named exports. The `new StatoscopeWebpackPlugin` calls have been replaced with `new StatoscopeWebpackPlugin.default` to reflect this change.
|
Strange that we do not catch it with tests |
|
Now we have a broken CI since we tested it Something strange happens. Can you investigate and send another PR (I will revert this one)? |
@ai Yes, I'll check. |
|
@ai, Hello After further investigation, I was unable to pinpoint the exact cause of the issue. However, I've observed that depending on the project, the module in question may operate in either ES or CommonJS mode. To prevent any issues between the two module systems, I've made the necessary code fix and submitted the PR. I would appreciate your feedback on this. all tests are passing. |
TypeError: StatoscopeWebpackPlugin is not a constructorerror.An error
TypeError: StatoscopeWebpackPlugin is not a constructoroccurs if the module does not export as default.@ai Hello, I wanted to bring to your attention an issue I've found while utilizing the
@size-limit/webpack-whypackage. Since I got an error message (StatoscopeWebpackPlugin is not a constructor), I have consulted with the official documentation. They advised that the class should be imported using the default export.I have submitted a PR addressing this matter and would greatly appreciate it if you could take a moment to review the proposed changes. Your feedback would be invaluable.