Skip to content
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

warn.code for missing output.name of IIFE bundle that has export #3372

Merged
merged 5 commits into from Mar 6, 2020

Conversation

rail44
Copy link
Contributor

@rail44 rail44 commented Feb 6, 2020

This PR contains:

  • bugfix
  • feature
  • refactor
  • documentation
  • other

Are tests included?

  • yes (bugfixes and features will not be merged without tests)
  • no

Breaking Changes?

  • yes (breaking changes will not be merged unless absolutely necessary)
  • no

List any relevant issue numbers:

Description

Hi, I'm using rollup with typescript.
In my project, there are some modules built as iife, because they must assign some object into window when loaded .
But it also has export since its member's type definition was used by other modules.
In this case, rollup will warn that bundle is missing output.name.

This is request to add warn.code, useful for suppress by onwarn() .

@rail44
Copy link
Contributor Author

rail44 commented Feb 6, 2020

writing test

@codecov
Copy link

codecov bot commented Feb 6, 2020

Codecov Report

Merging #3372 into master will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@           Coverage Diff           @@
##           master    #3372   +/-   ##
=======================================
  Coverage   93.29%   93.29%           
=======================================
  Files         172      172           
  Lines        6114     6114           
  Branches     1823     1823           
=======================================
  Hits         5704     5704           
  Misses        218      218           
  Partials      192      192
Impacted Files Coverage Δ
src/finalisers/iife.ts 100% <ø> (ø) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update eeda078...2b3e3ef. Read the comment docs.

Copy link
Member

@lukastaegert lukastaegert left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A code should definitely be added, but I think it should be aligned with the corresponding error for UMD bundles 'You must supply "output.name" for UMD bundles.', because it is about the same issue. This one is using INVALID_OPTION, though, which I am not really happy about as not passing a name IS valid if there are no exports. Would you consider changing the code in umd.ts to MISSING_NAME_FOR_EXPORT? You might also slightly tune the error message, e.g. You must supply "output.name" for UMD bundles that have exports.

@rail44
Copy link
Contributor Author

rail44 commented Feb 7, 2020

@lukastaegert
Thank you for your suggestion!

Then, should IIFE bundles also publish error, instead of warning?
And, when this PR will include such changes, it will become breaking change for people already having onwarn() with INVALID_OPTION won't it?

@lukastaegert
Copy link
Member

You are somewhat right about the breaking change. Maybe we should make a separate PR for changing the error code to the release-2.0.0 branch. Then I would actually just merge this one as it is. Note though that since it is an error, not a warning, it will not get passed to onwarn handlers. The only way to see the code for errors is to use the JavaScript API and catch the call to bundle.generate.

Then, should IIFE bundles also publish error, instead of warning?

If it produces working code, no reason to make it an error IMO. It's always possible someone depends on this...

@rail44
Copy link
Contributor Author

rail44 commented Feb 20, 2020

@lukastaegert

Sorry for late reply. I was under busy.
I also create #3393 for UMD bundle.

@lukastaegert
Copy link
Member

Let's wait how the discussion in #3393 pans out before merging

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants