Remove vue-server-renderer as a peer dependency

[eddyerburgh]

What problem does this feature solve?

renderToString was added in beta.12 , which uses vue-server-renderer.

I don't expect many users will call this method, as it's intended use is for testing server side code. Adding it as a peer dependency will warn users that they need to install it, even though they probably won't use the renderToString method.

What does the proposed API look like?

1. Remove vue-server-renderer as a peer dependency and handle it ourselves, using something like ensureRequire—https://github.com/vuejs/vue-jest/blob/master/lib/compilers/haml-compiler.js#L6. Users will still need to add additional config to webpack, because webpack will try to bundle native node modules in vue-server-renderer.
2. Split @vue/test-utils, and @vue/server-test-utils. @vue/test-utils will expose mount and shallow, @vue/server-test-utils will expose renderToString.

[lmiller1990]

Seems reasonable to me.

[timoschwarzer]

This breaks compatibility with tests that utilize webpack, too. For example with mocha-webpack:

[eddyerburgh]

@timoschwarzer A temporary workaround is to add this to your webpack config:

{
  node: {
    fs: 'empty',
    module: 'empty'
  }
}

See webpack/css-loader#447

This isn't a great solution, and we shouldn't force users to add extra config. My suggestion of checking the package ourselves won't solve this problem.

We could split vue-test-utils into two packages, vue-test-utils and vue-test-utils-server 🤔

[lmiller1990]

I thought about this a bit more. Is there any merit to removing/splitting?

[eddyerburgh]

It would mean people could bundle with webpack without having to add extra config, and it would solve the peer dependency issue

[lmiller1990]

Can't people bundle with webpack either way? Maybe I don't fully understand this part.

Considering both packages are maintained by the Vue core team, is it so bad to have a peer dependency? I understand it's better not to have them, though.

[eddyerburgh]

vue-server-renderer uses node modules, like path and fs.

To bundle these with webpack and run in node you need to add target:node to your config.

If you want to bundle to run tests in the browser (like with karma), you need to tell webpack not to bundle the native node modules vue-server-renderer uses (like path and fs).

This extra config makes it more difficult to set up webpack to compile tests for either node or the browser.

I don't think renderToString will be used by most users. It has only been requested as a feature recently. So we're making the setup for tests more difficult to support a few users.

Instead, we could turn vue-test-utils into a monorepo that generates two packages. @vue/test-utils, and @vue/server-test-utils. @vue/test-utils will expose mount and shallow, server-test-utils will expose renderToString.

That way, most users can carry on bundling their tests with webpack, without additional config. Any users who want to test SSR could download @vue/server-test-utils.

[lmiller1990]

Ok, I understand now. Thanks for that explanation.

In light of this, your proposal seems best.

[eddyerburgh]

I'm working on converting the repo into a monorepo this week. I'd appreciate feedback on the structure once I've finished 😄

EDIT: WIP—#447

[juhasev]

To fix both issues with webpack you need to set both fs and module empty in your webpack config:

node: {
    fs: "empty",
    module: "empty"
}

[iraklisg]

@eddyerburgh 👍

So we're making the setup for tests more difficult to support a few users.

Thanks for pointing this out 😛