Remove v1 -> v2-specific transformations

[bitpshr]

What kind of change does this PR introduce?
Feature

Did you add tests for your changes?
Yes

If relevant, did you update the documentation?
N/A

Summary
The loaders, loaderOptionsPlugin, and resolve transformations are specific to v1 -> v2 upgrades and as such are no longer needed. This PR removes these transformations and updates migrations test snapshots accordingly.

Resolves #383
Resolves #384
Resolves #388

Does this PR introduce a breaking change?
Yes. This PR removes previously-existing transformations and aims to produce a v4-compatible configuration instead of a v2-compatible configuration.

[evenstensberg]

I think that we can keep this for a bit longer. What's the damage around keeping the file?

[dhruvdutt]

I think we should keep this code, maybe at some other place.
Can we support migration to different versions by picking the current version from package.json or something?

[evenstensberg]

no. That would raise an incredible amount of tech debt in the length.

[bitpshr]

Thanks for the thoughts @ev1stensberg @dhruvdutt. It sounds like we have three options:

1. Remove the code altogether. The transformation is firmly v1 -> v2 specific, and git provides historical record of the code if we ever need to reference it or use it in the future (which is unlikely.)
2. Leave the code in-place so the transformation continues to be tested and maintained, but remove it from the transforms object since it's no longer relevant or supported.
3. Do nothing; leave the code in place and leave the transformation active.

I personally vote for option 1. While there's technically no harm in leaving the code in-place, it does add to both the bundle size and maintenance burden for functionality that is no longer relevant or supported in any way. Leaving the code in place also misleads anyone who is reading our source code. I feel that if our transformations are now v3 -> v4, we should be uniform across the board.

Regardless of whether we go with option 1 or option 2, I don't think option 3 is valid: we should not be migrating v1 configurations anymore, especially only for specific transformations. At the very least, we need to disable this transformation, but I can't think of a concrete reason not to also remove it.

[dhruvdutt]

@bitpshr I would say let's keep it till we get the migration for 3 to 4 to a stable point and then we can clean up. :)

[ematipico]

I personally think that we should move on and stop maintaining code for old versions of webpack, especially version 1. If in the future there would be bugs, we can always go back and make a patch. Versioning systems are made for these kind of situations.

[bitpshr]

Thanks for the input @ematipico @ev1stensberg @dhruvdutt . Since it sounds like we're deciding to go ahead and nix the dead v1 - v2 code, let me know if you'd like anything cleaned up before landing.

[ematipico]

I am personally fine with this change. Awesome job!

[evenstensberg]

Sounds good to me, needs a rebase before merge

[webpack-bot]

@bitpshr Thanks for your update.

I labeled the Pull Request so reviewers will review it again.

@ematipico Please review the new changes.

[webpack-bot]

Thank you for your pull request! The most important CI builds succeeded, we’ll review the pull request soon.

[bitpshr]

Thanks @ev1stensberg and @ematipico. Rebased.