refactor: use webpack instead of webpack-sources

[yoannmoinet]

Coming from the discussion unjs/community#37

Having a dependency on webpack-sources forces plugin developers to break the compatibility webpack/webpack-sources by having them declare a dependency on webpack-sources instead of a peerDependency on webpack.

Instead, we could require webpack-sources as webpack using:

import { createRequire } from 'module'
[...]
const webpackRequire = createRequire(require.resolve('webpack'))
const RawSource = webpackRequire('webpack-sources').RawSource

And remove any dependency on webpack-sources or webpack.

The change "should" be mostly invisible.

• Confirmed in both webpack 4 and 5 projects.

[pkg-pr-new]

Open in Stackblitz

pnpm add https://pkg.pr.new/unjs/unplugin@431

commit: dced339

[yoannmoinet]

I will have a look at the failing test later today.

[yoannmoinet]

🤔
I'm having difficulties to understand why the test started failing here after the main merge.
I can't reproduce it locally.
Anyone can assist here?

It doesn't seem to be super deterministic either.

[yoannmoinet]

Do you know why the test is failing @sxzz?

[yoannmoinet]

So sorry for hammering, but I'm stuck on this on a separate PR.
Any update @sxzz?
Also summoning @antfu, maybe you'll have an idea of what the issue may be.

[sxzz]

It's OK. I'll check it out when I have time.

[sxzz]

I believe PR is not compatible with Webpack 4.

[yoannmoinet]

Thank you so much for looking into it.

I'll have a better look, I don't understand why it's not always failing though.
I thought the fallback here was specifically for this case where webpack doesn't use webpack-sources (aka in webpack 4).
Webpack 4 does use webpack-sources, but it doesn't re-export it 😞

unplugin/src/webpack/context.ts

Lines 48 to 58 in dd9d184

	sources
	? new sources.RawSource(
	// @ts-expect-error types mismatch
	typeof emittedFile.source === 'string'
	? emittedFile.source
	: Buffer.from(emittedFile.source),
	) as any
	: {
	source: () => emittedFile.source,
	size: () => emittedFile.source!.length,
	},

I'll double check how webpack 4 works there, and if it actually needs webpack-sources or not (it does use it).

[yoannmoinet]

So, I couldn't find a good solution for webpack 4.

What I propose, to keep the best compatibility possible between webpack and webpack-sources is:

• Add an optional peerDependency on webpack-sources@^1.4.1 (version used by latest webpack@4).
• If require('webpack').sources exists, use it.
• If require('webpack').sources doesn't exist, use require('webpack-sources').RawSource instead.
• Add documentation about adding a dependency on webpack-sources:^1.4.1 for plugin developers so they don't break dependencies or side-load a potentially non-existing dependency.

This way we keep the compatibility most of the time, and do our best for webpack 4.

Cf: webpack/webpack#11345

Plugins should consume require("webpack").sources instead of require("webpack-sources") to avoid version conflicts for persistent caching

WDYT @sxzz ?

[yoannmoinet]

I went a different route after all.
It appears that you can actually require a package as a different dependent.

In our case we wanted to require the same webpack-sources as our peer webpack.

Doing:

import { createRequire } from 'module'
[...]
const webpackRequire = createRequire(require.resolve('webpack'))
const RawSource = webpackRequire('webpack-sources').RawSource

Makes it require the correct webpack-sources that our peer webpack expects.
And, we don't need to declare any of them as peerDependencies anymore.

(But, plugin developers should still declare their plugin's bundler as peerDependencies)

And it seems to pass the tests now 🙌

[sxzz]

I need to test the PR more, please hold on.

[yoannmoinet]

So sorry to ping you again @sxzz.
Did you have a chance to test the PR as you wanted? Can I help you in any way?

[sxzz]

LGTM