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

feat: Add ignoreOrder flag #422

Merged
merged 6 commits into from Jul 15, 2019
Merged

feat: Add ignoreOrder flag #422

merged 6 commits into from Jul 15, 2019

Conversation

mjhenkes
Copy link
Contributor

@mjhenkes mjhenkes commented Jul 10, 2019

This PR contains a:

  • bugfix
  • new feature
  • code refactor
  • test update
  • typo fix
  • metadata update

Motivation / Use-Case

Picking up the torch where #366 left off and making the changes suggested by @evilebottnawi
Also addresses #362
Borrowing @hedgepigdaniel 's description:

As has been pointed out in #250:

  • Sorting all imports (not just in files but in tree traversal import order is difficult to do in a large project, and impossible if there are async chunks with CSS.
  • Consistent use of scoping or naming conventions in CSS makes the order of CSS import irrelevant, and this is a much more manageable strategy for a large project as @jsg2021 said in New version 0.4.2 capture lot of warnings #250 (comment)
  • Using stats.warningFilter as recommended by @sokra in New version 0.4.2 capture lot of warnings #250 (comment) or webpack-filter-warnings-plugin does not work consistently. It's much better to avoid generating the warnings at their source (optionally) rather than to partially filter them later with regexes. For example, I use webpack-error-on-warnings-plugin to enforce that there are no warnings in a build. This is incompatible with filtering warnings, because it the error must happen in the before-emit hook so that it prevents emission of assets when there are warnings. The warnings filtering happens in the done hook or in the toJson method, which is too late.

Breaking Changes

None

Additional Info

The added tests is to ensure that enabling the flag doesn't make the plugin implode, but it doesn't really programmatically verify the warnings aren't printed.

fixes #362

@jsf-clabot
Copy link

CLA assistant check
Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

@kubijo
Copy link

kubijo commented Jul 15, 2019

Can someone from mainteiners merge this please.
The code seems nice, terse and without conflicts, so this should be a quick pass-over

@hedgepigdaniel hedgepigdaniel mentioned this pull request Jul 15, 2019
6 tasks
Copy link
Member

@alexander-akait alexander-akait left a comment

Choose a reason for hiding this comment

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

Please add test with ignoreOrder: false

@mjhenkes
Copy link
Contributor Author

@evilebottnawi technically all the other tests are testing ignoreOrder: false, but i've added an explicit test.
I've also updated the package-lock file, it started failing due to npm audit.

Copy link
Member

@alexander-akait alexander-akait left a comment

Choose a reason for hiding this comment

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

We need check stats.warning is empty or not in tests otherwise tests doesn't make sense

@mjhenkes
Copy link
Contributor Author

@evilebottnawi added

Copy link
Member

@alexander-akait alexander-akait left a comment

Choose a reason for hiding this comment

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

Good job, three notes

cache: false,
});
compiler.run((err1, stats) => {
expect(stats.hasWarnings()).toBeTruthy();
Copy link
Member

Choose a reason for hiding this comment

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

toBe(true)

Choose a reason for hiding this comment

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

just wondering why toBeTruthy(); is "better". Seems like the exact same shit to me...

Choose a reason for hiding this comment

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

cache: false,
});
compiler.run((err1, stats) => {
expect(stats.hasWarnings()).toBeFalsy();
Copy link
Member

Choose a reason for hiding this comment

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

toBe(false)

@@ -0,0 +1,44 @@
import path from 'path';
Copy link
Member

Choose a reason for hiding this comment

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

rename file ignoreOrder-option.test.js

Copy link
Member

@alexander-akait alexander-akait left a comment

Choose a reason for hiding this comment

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

👍

@mjhenkes
Copy link
Contributor Author

Do we need more approvals?

@alexander-akait alexander-akait merged commit 4ad3373 into webpack-contrib:master Jul 15, 2019
@mjhenkes
Copy link
Contributor Author

Thanks @evilebottnawi! 🎉

@kubijo
Copy link

kubijo commented Jul 16, 2019

Yeah, thanks a lot guys!
What is the release process now?

@alexander-akait
Copy link
Member

Today

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.

ignoreOrder option
5 participants