Feature Request : package it as monorepo about elix HOT 9 CLOSED

On that note is it possible to es6 import separate components in a js module, e.g. in a Ract, Vue or Angular component?

from elix.

@mrin9 Thanks so much for making this request!

It's been a very long time since we re-evaluated our packaging strategy, so your request has been provided a good opportunity to check how we're doing things.

First, some observations:

1. We previously treated the predecessor library to Elix as a monorepo that published a separate package for each component. That was a non-trivial complication of the publishing process: not a huge pain, but not trivial either. It was a big relief when we could just do npm publish again when we started Elix.
2. Elix relies heavily on reuse in building components from base classes, smaller components, JavaScript mixins, and helper functions. It turns out that a single component like Carousel ends up pulling in about 6 other components, 20 component mixins, and a dozen helpers, or about 1/3 of the total Elix source. As a result, depending on a specific component package instead of the overall Elix package wouldn't help you as much as one might imagine.
3. Another implication of the above point is that, roughly speaking, if you were to add more than 3 Elix components to a project, you'd be better off depending on the overall Elix package than on specific packages. So any monorepo strategy would probably deliver its benefit to the people using just 1–3 components. That might be a substantial fraction of our users, but it's not everyone.
4. We've tried in the past to identify an elix/core package of the most essential source files. But given our reuse strategy, it was nearly impossible to define such a core. There's too much reuse across components to make that worthwhile.
5. Publishing a single package means that we ourselves are always testing the consumption of the library the way everyone else will. For a project of our size, that's really helpful.
6. We're currently being dumb about publishing to npm: we publish everything in the repo except things which npm automatically ignores. So your local copy of Elix includes tests, demos, image files used by those demos and, worst of all, a copy of the web components polyfill used by the demos. That's dumb. Cutting out all the junk looks like it reduces our disk impact by 80–90%.

The last point is easy enough to fix with the creation of an .npmignore file. We'll add in our forthcoming 4.0 release. I can point you at that when it's ready for testing to see whether that helps you.

Beyond that, I think for now our current single package approach delivers the best cost-benefit ratio for us. But your suggestion reminds us that we should keep checking that assumption. As our library grows, there may come some tipping point where publishing individual components begins to be a better option.

Please let me know what you think.

from elix.

@Nudelsieb Your issue sounds like a separate issue. Can you please file that separately and provide some more detail on what you're trying to do? I'm not quite sure I understand the question.

from elix.

hmm, given the situation I agree with you.
The other option that I can think of is to use a bundler like webpack and generate a single chunk for each component. Webpack should take care of importing all its dependencies and generate a standalone output of each component say in dist folder and then people like me can just use a

<script src="https://unpkg.com/elix@(version)/dist/component.js"></script>

although I dont know, can we cleanly create such bundles with webpack.
But if it is too much of a hassle, let things be as is we can revisit this later

from elix.

You could make the mixins and the components npm packages and the rest is just used as is. Some redundancy is not bet if it leads to and easier to use and/or more efficient product.

WRT to a core module: I just had a quick look and most of your components make regular use of
updates.js, symbols.js and template.js. Maybe it's woth combining this.

WRT to my question above is that I did not really know how to add components to a project. I want to avoid script tag. So and ES6 import in a module that wants to use a component should be good. But as it stands now that's not possible, given the reasons above. So do I just import the whole project as ES6 module?

from elix.

Another note. My use case is that I would like to use your Carousel in my own web component (created with StencilJS), but I do not want to include the whole library just for one component.

from elix.

@mrin9 A significant problem with distributing bundled output like that, and a general problem with creating packages for each component, is that each bundle ends up with its own copy of the shared Elix files.

• Two components that look very different, such as Carousel and Tabs, actually share something like 90% of their code. So someone who imports both packages ends up with substantial duplication.
• Our components currently auto-register themselves with the browser. Since two distinct components may easily share subelements, each packaged component will try to register the subelement. E.g., both Carousel and Tabs will try to register an element with the name elix-explorer. The second such registration attempt will fail and throw an exception. We'd like to eventually offer ways of importing components without auto-registration, but that's a separate piece of work.

For now I'd like to close this issue, then revisit periodically to see if it would be appropriate to tackle this. I'm hoping we can eventually work towards making it very easy to use a single Elix component in a project.

from elix.

@Nudelsieb If the Quick Start section I added for #86 doesn't help, please file a separate issue. Thanks.

from elix.

Just following up on this now that Elix 4.0.0 has been released with a much smaller package footprint.

Package size is now 150K over the wire, 587K uncompressed. The previous on-disk size, not counting devDependencies, was more than 20MB.

@mrin9 Many thanks for your suggestion, which prodded us to take care of this!

from elix.