Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Merged
merged 5 commits into from
Oct 18, 2022

Conversation

IanVS
Copy link
Member

@IanVS IanVS commented Oct 7, 2022

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
Copy link
Member

yannbf commented Oct 10, 2022

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

@ndelangen
Copy link
Member

ndelangen commented Oct 11, 2022

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
Copy link
Member Author

IanVS commented Oct 11, 2022

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
Copy link
Member Author

IanVS commented Oct 11, 2022

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
Copy link
Member

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

@IanVS
Copy link
Member Author

IanVS commented Oct 12, 2022

@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
Copy link
Member Author

IanVS commented Oct 12, 2022

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
Copy link
Contributor

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
Copy link
Member Author

IanVS commented Oct 18, 2022

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
Copy link

socket-security bot commented Oct 18, 2022

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 foo@1.0.0 bar@2.4.2

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

Powered by socket.dev

@IanVS
Copy link
Member Author

IanVS commented Oct 18, 2022

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

Copy link
Member

@shilman shilman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@shilman shilman changed the title Build: Make babel-loader an optional peer dependency Addon-docs: Make babel-loader an optional peer dependency Oct 18, 2022
@shilman shilman merged commit 9bd628d into next Oct 18, 2022
@shilman shilman deleted the optional-webpack branch October 18, 2022 14:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants