Migrate to webpack-dev-server to 4.0.0

[th7nder]

#11278 (reply in thread)

Fixes error overlay formatting by upgrading webpack-dev-server.

[facebook-github-bot]

Hi @th7nder!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at [email protected]. Thanks!

[facebook-github-bot]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks!

[mrmckeb]

I'm not sure why this is failing in the CI, I'm seeing this issue that I saw on a friends project recently:

Though the "loose" option was set to "false" in your @babel/preset-env config, it will not be used for @babel/plugin-proposal-private-property-in-object since the "loose" mode option was set to "true" for @babel/plugin-proposal-private-methods.
The "loose" option must be the same for @babel/plugin-proposal-class-properties, @babel/plugin-proposal-private-methods and @babel/plugin-proposal-private-property-in-object (when they are enabled): you can silence this warning by explicitly adding
	["@babel/plugin-proposal-private-property-in-object", { "loose": true }]
to the "plugins" section of your Babel config.

@raix I see this:
https://github.com/facebook/create-react-app/blob/main/packages/babel-preset-react-app/create.js#L151-L153.

But the third isn't actually there, is that intentionally omitted, or could that be why we're seeing this issue?

[th7nder]

@mrmckeb @raix
In the meantime (10 minutes ago, webpack version 4.0.0 got released), so I changed it.
If it's about those warnings, when I added the rule @babel/plugin-proposal-private-property-in-object warnings disappeared.

[th7nder]

Looks like the build broke, after changes added in 4.0.0. Investigating.

[raix]

@mrmckeb babel was just warning about a missing loose setting, Thanks @th7nder for fixing that one.

I might be able to qa why 4.0.0 breaks the build tomorrow, could not see any breaking changes in wds rc.1

[th7nder]

@raix I found some issues and fixed them. According to: https://github.com/webpack/webpack-dev-server/blob/master/migration-v4.md. We had some incompatibilities in on(Before|After)SetupMiddleware and .listen() was marked as deprecated, so changed it to .startCallback().

[raix]

Awesome work @th7nder ! Great to see they added a migration guide from 3 to 4 :)

Not sure why the integration tests stopped working (maybe they just need a rerun 🧐)

[raix]

It fails to load object-assign, seems related to babel - also a warning asking to update corejs to >3.3 - maybe we need to update a dependency in babel preset for it to pass 🧐

[th7nder]

@raix It's weird, because I cannot reproduce it locally, even after removing my local yarn.lock.
yarn test:integration just passes (Node 14, Ubuntu 20.04). I don't think this error is related to this warning.

[raix]

The build seem to fail loading object-assign from localhost - maybe it's a caching issue on the build server

[th7nder]

How do we check if this is the issue with the build server? Can we clear the cache somehow?

[th7nder]

If I think correctly, our cache dependencies step in the github workflow arent't the best.

      - name: Cache dependencies
        id: cache
        uses: actions/cache@v2
        with:
          path: |
            node_modules
            */*/node_modules
          key: ${{ runner.os }}-${{ hashFiles('**/yarn.lock', './yarn.lock') }}
      - name: Install packages
        if: steps.cache.outputs.cache-hit != 'true'
        run: yarn --frozen-lockfile --prefer-offline
      - name: Run integration tests
        run: yarn test:integration

We base our cache on yarn.lock, but it's not committed to the repo either way. In the end it tries to get packages from local cache which is based on I don't know what.

[raix]

Not sure if this is the issue: Reading the '.github/integration' file it seems that we try calculating the cache invalidation hash of yarn.lock - I'm not sure this works as we dont check in yarn.lock files...
The only lockfile we check in is packages/create-react-app/yarn.cached.lockfile (running 'yarn compile:lockfile' will update it)

Not sure if the github integration cache should use the compiled lock file for generating the hash for cache invalidation @mrmckeb @iansu ?

[raix]

@th7nder we could try using the compiled lock file - otherwise comment out the cache step to see if that fixes the issue

[raix]

Thanks @th7nder all green and merged (the 'yarn compile:lockfile' seemed to solve the issue)

[mrmckeb]

Thanks all!