fix(webpack): fix usage of webpackResolveOptions conditionally

[jpnelson]

Motivation

There's no existing issue for this as far as I know.

Fixes an issue like this:

INFO ==>  ModuleBuildError: Module build failed (from ./node_modules/thread-loader/dist/cjs.js):
--
INFO ==>  Thread Loader (Worker 6)
INFO ==>  Cannot read property 'extensions' of undefined

Summary

There are some contexts in which the webpackResolveOptions might be undefined – eg issues like TypeStrong/ts-loader#1206 .

In general the loader handles this._compilation not being there, but in practice, breaks because of this line. You can see on line 86 that this is meant to handle the case where webpackResolveOptions is undefined, but it was just missed there (if only we could do it in typescript! But I imagine that's more trouble than it's worth for a webpack loader)

You can compare this with linaria@^2.0.0 to see how it differs in the @linaria/webpack4-loader

Test plan

Tested locally by patching the module with this change

[Anber]

Hi @jpnelson!

Could you please fix it in webpack5-loader as well?

[Anber]

Optional chaining should help here: webpackResolveOptions?.extensions?.length === 0)

[jpnelson]

Good call @Anber , updated now! Thanks

[jeremy-ww]

Hi @jpnelson, thank you for providing us with such a useful library. And I have encountered the same error there. It's splendid to see a PR issued already before my action. But, I would like to share more information with you guys:

1. This error occurred to me with the pre-release version @linaria/webpack-loader@3.0.0-beta.16.
2. Of course, I tried to downgrade it to the pre-release version @linaria/webpack-loader@3.0.0-beta.13.
3. The error still exists.

Why?

Since the @linaria/webpack-loader@3.0.0-beta.13 is depends on the @linaria/webpack5-loader: ^3.0.0-beta.13. And yarn will always download the latest version of @linaria/webpack5-loader:

So I would like to suggest you lock the version without any range modifier or use the distribution tag like next, beta to avoid confusing conditions like that.

Temporarily workaround:

package.json

{
  "resolutions": {
    "**/@linaria/webpack-loader": "3.0.0-beta.13",
    "**/@linaria/webpack5-loader": "3.0.0-beta.13"
  }
}

[jeremy-ww]

Hi @jpnelson, thank you for providing us with such a useful library. And I have encountered the same error there. It's splendid to see a PR issued already before my action. But, I would like to share more information with you guys:

1. This error occurred to me with the pre-release version @linaria/webpack-loader@3.0.0-beta.16.
2. Of course, I tried to downgrade it to the pre-release version @linaria/webpack-loader@3.0.0-beta.13.
3. The error still exists.

Why?

Since the @linaria/webpack-loader@3.0.0-beta.13 is depends on the @linaria/webpack5-loader: ^3.0.0-beta.13. And yarn will always download the latest version of @linaria/webpack5-loader:

So I would like to suggest you lock the version without any range modifier or use the distribution tag like next, beta to avoid confusing conditions like that.

Temporarily workaround:

package.json

{
  "resolutions": {
    "**/@linaria/webpack-loader": "3.0.0-beta.13",
    "**/@linaria/webpack5-loader": "3.0.0-beta.13"
  }
}

Updated: Sorry to ping jpnelson by mistake, it should be @satya164 @Anber. :)

[ntucker]

Can we get a release? this is a pretty big bug since webpack 5 doesn't work at all here

[Anber]

@ntucker I'll publish the next beta later today or tomorrow.

[Anber]

Hi @ntucker
Sorry for the delay, but critical issue #891 has been found and should be fixed before the release.

[selmalee]

When will this fix be released please?

[wmzy]

@Anber could you publish this to latest tag?

[Anber]

@wmzy done!