Theme isn't provided in a monorepo

[dmitriy-kudelko]

Hey guys,

We're working on a few custom Flex plugins which have many things in common. So an obvious choice for us was to store plugins in a monorepo and have a shared package in the same monorepo for sharing a reusable code between the plugins. What we would like to eventually achieve is to have a library of shared components, including a wrapper around Theme.Provider (or CustomizationProvider) which we can then re-use in all plugin packages without duplicating some theme settings, e.g. custom breakpoints.

It turned out to be tricky to make it all work in a monorepo, and one of the issues that we faced was the inability to apply Twilio Paste theme to React components imported from a shared package. It seems that styles simply do not apply.

Now I have a reproducible example in this repo: https://github.com/dmitriy-kudelko/flex-plugins. It is based on yarn workspaces.

Basically the way it works is that we pre-bundle the shared package using esbuild excluding all peer dependencies (react, @twilio-paste, etc.) The package also contains the rollup build configuration producing a similar result (we first though that it might be something wrong with the way esbuild bundles the code).
Then we import the shared package from within the plugin-sample package, which is a standard flex plugin generated via Twilio Flex CLI.

Now a problem is that when we use a component locally defined in the plugin-sample package, we aren't able to wrap it with just SharedThemeProvider, because in this case styles do not apply.

Similarly if we import some shared component from the shared library to plugin-sample and this time wrap it with a local import of ThemeProvider, then again it renders unstyled.

And the only combination when both types of components work is when we wrap them in both local and shared theme providers.
However this doesn't seem right as I would expect theme to be provided when using just the shared theme provider.
Using both is troublesome (and doesn't feel right) because for example CustomizationProvider wraps child elements in a div. And wrapping the component tree in two providers would produce two nested divs which causes some troubles to us.

So is Twilio Paste monorepo-ready?

I would really appreciate if you can have a look and provide some help, as it's kinda a show stopper for us at the moment.

This question is somehow similar to #1591. However it doesn't seem that any of the answers there are relevant.

Thanks!

[TheSisb]

Hi @dmitriy-kudelko,

Theoretically, this should work just fine. I'm unable to to build your sample repo locally because of the hard dependency on Flex, however if you can provided a generic reproduction without that dependency I would be able to test it. It would also help us better determine if the issue is coming from Paste, the implementation, or the Flex plugin system - in your repo things are a little too coupled to figure that out easily.

Another thing I'm thinking about looking at this, is when compilation/bundling should happen. It could be that because you're compiling things separately, by the time the final bundling is happening references are getting lost. Maybe you can ship the source and do bundling once at the final plugin level? That may make debugging what's happening at the end easier if you can peek at the source without minifaction.

[dmitriy-kudelko]

Hi @TheSisb 👋

First of all thank you for the quick turnover!

I've updated the example and instructions to include Storybook so that you're able to easily reproduce the issue.
TBH, I'm not sure any more that it's specific to Twilio Paste, because I've found similar issues with inability to use context exported from a shared library in monorepos. For example: TanStack/query#3595

I also followed one of suggested solutions from the aforementioned thread - to alias dependencies in Webpack config, and it worked. The only issue is that it's seem to be more like a hack/patch. And I still don't have a good answer why this is happening in the first place. So if you uncomment this it magically starts working.

Regarding bundling the code differently... Well, I've tried it either ways. But the thing is that the code which creates context is executed in the browser and not when we bundle the code. So in theory this shouldn't matter.

[SiTaggart]

Is it just the context that's the problem? So, if you create shared components, just components on their own, install them into an app (A plugin is technically an app as I'm fairly certain they each have a react root), and the app has its own theme provider installed directly from Paste, do those get the theme context and style correctly?

If so, whatever you're trying to share as a common theme provider, you could probably just share as a JSON object to kind of get around it.

It does seem like there's some React context reexporting and sharing issues that causes a problem.

[dmitriy-kudelko]

@SiTaggart , I think yes, it's mostly the context. I didn't notice any other issues.

So, if you create shared components, just components on their own, install them into an app (A plugin is technically an app as I'm fairly certain they each have a react root), and the app has its own theme provider installed directly from Paste, do those get the theme context and style correctly?

No, not really. But it seems that it only happens with a context created by one of dependencies. If I define context in the shared library myself (or in the plugin A and try to access it from within a shared component), it works.

And AFAIU now, it's more related to the way Webpack resolves modules in monorepo, than to Paste which I first thought.
My initial thinking was that if I pre-bundle the shared library without peer deps, then it's gonna pick them from the consuming package. But this is just not the case. Webpack first resolves modules then bundles and not vice-versa. So it picks Paste from both the shared library and then from the consumer module, and this is how two independent Theme contexts are created. But if we force Webpack to first look at node_modules relative to the consuming package, then it finds it there and bundles just one:

module.exports = {
  resolve: {
    modules: [
      path.resolve(__dirname, 'node_modules'),
      path.resolve(__dirname, '../node_modules'),
      'node_modules'
    ]
  }
};

Also attaching link to article which helped me, just in case it might be useful for someone.

We can mark this as resolved, mistery solved :)

Thank you guys for your time!

[TheSisb]

Thanks for reporting back with the answer. I'm sure this will be helpful to others in the future <3