Addon-docs: Make babel-loader an optional peer dependency

[IanVS]

Issue:

What I did

The webpack babel-loader was listed as a dependency of addon-docs, and a required peer dependency of renderers/vue and renderers/vue3. Since all of these can be used with vite, which does not require babel-loader, I've moved them to optional peer dependencies.

I suggest that if necessary, babel-loader could be added as a dependency or peer dependency of the webpack frameworks if we want to ensure that it's available for addons.

How to test

• CI

[yannbf]

Thanks @IanVS ! Seems like @ndelangen has an interesting idea, can you please discuss with him and possibly @shilman ?

[ndelangen]

I think we should not have more peerDependencies, they do not actually fix the issue.

What we should do instead is have the reference to the babel loader come from a preset, probably the builder.

If the builder depends on babel-loader it could do something like this:

// builder/preset.js

export const babelLoaderRef = () => require.resolve('babel-loader');

in another place (docs addons):

// addons/docs/preset.js

const webpack = (config, options) => {
  config.module.rules.push({
    use: await options.presets.apply('babelLoaderRef'),
  });
  return config;
}

[IanVS]

I think that could work for this case, but it would also be great if we could find a more general solution. I'm hitting the same kind of issue in storybookjs/addon-svelte-csf#72, where svelte-loader and @sveltejs/vite-plugin-svelte are only needed in one builder or the other. They can perhaps reasonably be expected to exist in a project already, so peer deps might work, but I agree with you that they're a tire fire and can cause more problems than they solve sometimes.

[IanVS]

The CLI has a concept of extraPackages. I wonder if we could get away with using peerDependencies and adding them into that array to be sure that they're installed in the project. That wouldn't solve the issue for community addons though, and would be annoying for anyone who is not using the addon. Nevermind, forget I suggested that, I talked myself out of it.

[ndelangen]

@IanVS I expanded upon my comment, maybe you hadn't seen it / got no notification, so just doing a ping here, in case.

[IanVS]

@ndelangen do you envision we would follow this pattern for any and all dependencies that are specific to one of the builders for all addons, or just for babel-loader?

[IanVS]

I suppose the other option is to publish a webpack version and a vite version of such addons. They could have some common functionality shared between then, but publish separate packages with different dependencies and exports. It would be a shame, but might be the cleanest way to avoid the extra dependencies.

[benmccann]

At least for Svelte, a project won't work without vite-plugin-svelte or svelte-loader, so I wouldn't worry too much about having them as a peer dependency as the user will already have one installed

[IanVS]

We discussed this, and decided to take the approach of addingkeeping babel-loader as a dependency of @storybook/builder-webpack, and exposing its location on disk via require.resolve() as Norbert suggested above. It's not a general solution, but it might be a way to get us out of this particular hurdle, and we can see how well it works and whether it might be an approach we could use for other dependencies as well.

I think there's a good chance that using an optional peerDependency would also work here, but we've been bitten by peer deps in the past, so I don't blame folks for wanting to avoid them.

[socket-security]

Socket Security Report

👍 No new dependency issues detected in pull request

Socket.dev scan summary

Issue	Status
Did you mean?	✅ no new possible package typos
Install scripts	✅ no new install scripts
Telemetry	✅ no new telemetry
Troll package	✅ no new troll packages
Malware	✅ no new malware
Native code	✅ no new native modules

Bot Commands

To ignore an alert, reply with a comment starting with @SocketSecurity ignore followed by a space separated list of package-name@version specifiers. e.g. @SocketSecurity ignore [email protected] [email protected]

⚠️ Please accept the latest app permissions to ensure bot commands work properly. Accept the new permissions here.

Powered by socket.dev

[IanVS]

I also removed @babel/preset-env and lodash from addon-docs, since they appear to be unused.

[shilman]

LGTM! thanks for your patience @IanVS and help @ndelangen ❤️