storybookjs / storybook

Storybook is the industry standard workshop for building, documenting, and testing UI components in isolation
https://storybook.js.org
MIT License
84.7k stars 9.33k forks source link

Importing Meteor packages solutions? #3455

Closed DylanLyon closed 6 years ago

DylanLyon commented 6 years ago

Hey all,

I know there has been some talk in the past about handling Meteor import statements into storybook (e.g. 'import Random from meteor/meteor') but I never saw any concrete ways to make it work. Did anyone ever get a method working that doesn't involve rewriting all their code? (rewriting isn't really an option for this project.)

Thanks everyone for your help!

danielduan commented 6 years ago

I don't think anyone is looking into adding support. If you'd like to open a PR, we'll gladly take a look.

tmeasday commented 6 years ago

Hi @DylanLyon, I guess this is covered by this ticket: https://github.com/storybooks/storybook/issues/3329

I don't think explicitly supporting Meteor from within Storybook is the best way to solve it. Probably the best way forward in the shorter term is investigating things like https://github.com/ardatan/meteor-webpack and seeing if you can use that to make SB in it's current form work with Meteor (let us know if it works!)

ksinas commented 4 years ago

It's an old thread, but I run into the similar issue. So thought it might help someone. I usually try to make components without any Meteor logic and then wrap it in a separate file, so I could play around with storybook. In some cases there are still some dependences, but then I mock these dependences.

To do that, you need to setup webpack. This is how my .storybook/main.js file looks like:

const webpack = require('webpack');
const path = require('path');

module.exports = {
  stories: ['../stories/**/*.stories.jsx'],
  addons: ['@storybook/addon-actions', '@storybook/addon-knobs'],
  webpackFinal: async (config) => {
    config.plugins.push(new webpack.NormalModuleReplacementPlugin(
      /^meteor/,
      resource => {
        // Gets absolute path to mock `meteor` packages
        const absRootMockPath = path.resolve(
          __dirname,
          "../__mocks__/meteor",
        );

        // Gets relative path from requesting module to our mocked module
        const relativePath = path.relative(
          resource.context,
          absRootMockPath,
        );

        // Updates the `resource.request` to reference our mocked module instead of the real one
        resource.request = resource.request.replace(/meteor/, relativePath);
      },
    ));

    // Return the altered config
    return config;
  },
};

Then it's up to you to mock your dependences, which should be stored in __mocks__/meteor folder.

tmeasday commented 4 years ago

@ksinas would you be interested in looking at making a Storybook preset to encode this setup?

ksinas commented 4 years ago

@tmeasday to make an npm package out of it doesn't make much sense to me. At the end it's user's responsibility to write mocks. And if you don't try to write your components as pure as possible, there might be a lot to mock.. And a package like this might cause a lot of misunderstanding and bug reports.

If you have a good idea how to circumvent it, I don't mind making a preset.

tmeasday commented 4 years ago

I guess I just literally meant something to do the webpack config you posted above.

Having said that, I suspect a built-in mechanism in SB, maybe .storybook/mocks/<module-name> might be a good idea!