Lerna / Embroider and bundle size

[mrloop]

My understanding is that using Lerna was to allow downstream packages ability to only import mdc components that are required and thus the final bundle size is reduced as it would not include unused components. Now that Embroider is available and has tree shaking, which would achieve the same bundle size reductions by not including unused component should, would it be good to look at converting ember-cli-mdc to a v2 ember addon with native embroider support in a single monorepo. This would simplify the project and make things such as adding github actions, configuring ember-try easier, and maybe automating releases easier.

https://github.com/embroider-build/embroider/blob/master/ADDON-AUTHOR-GUIDE.md https://github.com/ember-cli/ember-cli/pull/9495 https://github.com/emberjs/rfcs/pull/746 https://blog.emberjs.com/the-road-to-ember-4-0/

[hilljh82]

@mrloop When I originally started this project, I wanted to have everything in a single add-on project. This is how I did it in ember-cli-mdl. When material-components-web became the de facto standard for using Material Design on the web, I had to take a different approach. This is because to be listed on material-components-web as a recommended framework, you have to deliver the components in an a-la-cart manner.

Now, I believe their rationale for this requirement is because it helps keep material-components-web footprint small. Forcing all web site to include all the scripts and styles (which I think is the best part of material-components-web) and to not use them would be not be good.

If we can still meet this criteria above, then we can give it a look at migrating. If not, then we may not be able to make the full migration as you suggest.

Either way, we need to make sure the different ember-cli-mdc components/projects are compatible with ember-embroider. We can put this on the roadmap for v4. We are currently working on v3, which will bring ember-cli-mdc up-to-date with material-components-web v13, and ember 3.28.

[mrloop]

This is because to be listed on material-components-web as a recommended framework, you have to deliver the components in an a-la-cart manner.

Thanks for the link. I found this issue https://github.com/material-components/material-components-web/issues/1521 and this PR for a vue project https://github.com/material-components/material-components-web/pull/1552 which uses a single package, albeit now deprecated. Reading the comments I think a single package embroider addon would meet the a-la-carte criteria.

I'll put together a POC. I'd like to use ember-cli-mdc for a project but lack of functioning test suite means I can't. Simplifying project as single package will make it straight forward for me to add github actions to run CI. Unless you have a big objection at this point which would prevent a POC being useful, for instance as a basis for future PR, I'd like to create a POC which migrates this package to a single package embroider v2 addon and adds github actions to run test suite using ember-try. Even if can't be used as is, because of v3 work, it'll let us see what steps are needed and structure for single package project.

[hilljh82]

@mrloop We will have to check first, and explain what we are hoping to achieve. It's important this project remains listed at this point in time.

On another note, a proof-of-concept would be great. If we can simplify the package structure, but still be able to install each component independently as required per Google, then I am all for it.

I have not viewed the vue package above, but one thing that comes to mind is maybe a "configurations" where you have to "turn on" each component you want to include. This will include the appropriate sources and styles. The only problem that comes to mind with this approach is "including" styles on-demand. We do not want to pollute the css space with unused styles, or unnecessarily increase the size of vendor.css.

[mrloop]

Took an alternative approach https://github.com/mrloop/ember-material-modifier