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
feat: Call namespace error as a warning #3475
Conversation
Again I have no idea why there are these trailing commas added or how to change that in the git hooks. |
Thank you for your contribution! ❤️You can try out this pull request locally by installing Rollup via
or load it into the REPL: |
Codecov Report
@@ Coverage Diff @@
## master #3475 +/- ##
==========================================
+ Coverage 95.81% 95.84% +0.03%
==========================================
Files 174 174
Lines 5898 5898
Branches 1736 1736
==========================================
+ Hits 5651 5653 +2
+ Misses 127 126 -1
+ Partials 120 119 -1
Continue to review full report at Codecov.
|
It's the new default of prettier@2. I will add a setting to change that. |
b28e871
to
0a46cd3
Compare
0a46cd3
to
acf0777
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good and I agree with the reasoning. I added tagged template literals to the tests as well to also cover this case in tests.
Thanks for the quick review! |
This converts the error when a namespace is called into a warning.
The reason being that there may exist valid runtime paths through the code that do not trigger the error, despite it being invalid. So allowing the build to proceed can allow valid runtime code to work despite the underlying "typing issue".
Alternatively it might be worth considering a strict / loose mode for Rollup "typing errors" so far as it cares about module semantics, but I actually think it would be better to treat Rollup as allowing anything to execute which would execute in a JS engine, since it is not a type system.
Landing as-is seems sensible to me, but I would be open to suggestions too.
This PR contains:
Are tests included?
Breaking Changes?
List any relevant issue numbers:
Description