# Getting addons ready to support First-Class Component Templates
**URL:** https://discuss.emberjs.com/t/getting-addons-ready-to-support-first-class-component-templates/19489
**Category:** Uncategorized
**Created:** [April 9, 2022, 2:29am UTC](https://discuss.emberjs.com/t/getting-addons-ready-to-support-first-class-component-templates/19489 "2022-04-09T02:29:08Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@ef4](https://discuss.emberjs.com/u/ef4)
#### Post date: [April 9, 2022, 2:29am UTC](https://discuss.emberjs.com/t/getting-addons-ready-to-support-first-class-component-templates/19489/1 "2022-04-09T02:29:08Z")
A public service announcement for addon authors:
[First-class component templates](https://github.com/emberjs/rfcs/blob/master/text/0779-first-class-component-templates.md) is a merged RFC and already has a working implementation. Users are going to want to consume your components from this new style of templates.
Mostly that will Just Work, but there are a few things you may not have considered.
1. **Use component template co-location**. This isn’t just nice for developer ergonomics – it makes components work as first-class values. Without it, your component can’t be passed around as a value in Javascript without losing its template.
2. Make sure the components (and helpers and modifiers) in your `/addon` folder have **reasonable filenames** , because those are going to be what people import from to use them.
First-class templates plus Glint is looking _really_ nice. If you haven’t had a chance to play with it give it a go.
---
### Author:  [@NullVoxPopuli](https://discuss.emberjs.com/u/NullVoxPopuli)
#### Post date: [April 9, 2022, 12:50pm UTC](https://discuss.emberjs.com/t/getting-addons-ready-to-support-first-class-component-templates/19489/2 "2022-04-09T12:50:59Z")
I certainly agree with everything said here, but say someone (consuming app) is in an embroider environment / already using a modern packager – how would one go about enabling tree-shaking?, or dealing with extra-exports packages that includes maybe 90% of stuff that isn’t used?
I know addon-authors can, by “just not providing a mono-re-exports file”, can prevent the need for the above, but it’s not always possible in big organizations where nearly anyone can make (or add to) an addon (and PR reviewers are not up to date on the current best patterns), or maybe the \_best DX for the situation is to setup your `import {} from 'my-library'` and let intellisense tell you everything in the library? – in these scenarios, tree-shaking seems like _an option_ (I assume trading production build speed for smaller JS size)
Webpack’s docs have this page: [Tree Shaking | webpack](https://webpack.js.org/guides/tree-shaking/)
I haven’t tried setting
```js
optimization: {
usedExports: true,
},
```
in an ember app though. Will try to remember to try this and report back.
Looks like on that same docs page though, addon-athors can specify in their package.json:
```js
{
"name": "your-project",
"sideEffects": false
}
```
> **`sideEffects` is much more effective** since it allows to skip whole modules/files and the complete subtree.
For _me_, since I have a couple addons that register _managers_, I think I’d need to set:
```js
{
"name": "your-project",
"sideEffects": ["./dist/initializers/setup-helper-manager.js"]
}
```
(because a side-effect is something that executes in module-space, such as `setHelperManager`)
---
### Author:  [@ef4](https://discuss.emberjs.com/u/ef4)
#### Post date: [April 9, 2022, 5:39pm UTC](https://discuss.emberjs.com/t/getting-addons-ready-to-support-first-class-component-templates/19489/3 "2022-04-09T17:39:45Z")
sideEffects false doesn’t work reliably for us yet.
The problem is that in many cases both embroider and ember-auto-import have to take advantage of webpack’s CJS support to get compatibility with older ember APIs. That means instead of importing the dependency, we `require` it. This defeats the in-module tree shaking.