Re-exporting public modules from 'ember-animated'

[samselikoff]

I wanted to reopen the discussion about exporting EA's modules from the top-level namespace:

// current
import { fadeIn } from 'ember-animated/motions/opacity';
import move from 'ember-animated/motions/move';

// proposed
import { fadeIn, move } from 'ember-animated';

I was chatting with @twokul and @kellyselden and they said Rollup had the ability to tree-shake this style of import. I know you mentioned it is not part of the language-level module specification, but if this feature of Rollup allows us to (eventually) tree-shake packages organized like this when the time comes, what do you think about moving things over today?

[ef4]

This is the same thing we already discussed. Rollup and webpack can both do this.

I think we should write into the v2 addon spec that all ember addons are required to be "side effect free" in the sense that this kind of transformation is safe. Then we can trust this pattern.

So ok, yes, let's design better imports. My remaining design concern is logical groupings. If we collapse things down too far people can't see what is a transition vs motion vs easing vs some other helper function provided by the library. One idea is to group into:

• ember-animated for the things that are already on the top-level
• ember-animated/motions to reexport all the motions
• ember-animated/transitions to reexport all the transitions
• ember-animated/easings to reexport all the easings

[samselikoff]

Super excited to think about standardizing around this in the wider community 🎉

I had the same thought, that

import { fade, fadeIn } from 'ember-animated';

would be confusing, since one is a motion and another is a transition.

I think your grouping idea makes perfect sense! 👍

[cibernox]

I just learned about that spec and I think it's great.

Do you think it would be possible to craft an ESLint rule that detects exported functions with side-effects, at least some of them?

[ef4]

We can lint for some potentially tempting Ember-specific things, like reopening a framework-provided class. But we definitely can't catch it all.

If these things were statically detectable, the whole problem would be a non-problem because instead of linting you could do the analysis in the module bundlers and they could automatically know which code is safe to strip.

[samselikoff]

I understand why they are not statically detectable (otherwise it'd be part of the language spec), but in that case how do the Webpack/Rollup features work?

[ef4]

Webpack makes npm package authors certify that they’re safe by setting a value in package.json.