Tripped up by easing imports about ember-animated HOT 7 CLOSED

(It's an ember-cli deficiency that this isn't a static build error. The point of imports is that they are analyzable. In embroider this is a build error, as it should be.)

I agree there is inconsistency here.

An index has the nicest user experience, my only hesitation is that there's no completely-spec-compliant way to then shake out unused easings.

Another option is to standardize on always using default exports:

import easeOut from 'ember-animated/easings/ease-out';
import easeIn from 'ember-animated/easings/ease-in';
import linear from 'ember-animated/easings/linear';

Or standardize on only named exports:

import { easeOut, easeIn } from 'ember-animated/easings/cosine';
import { linear } from 'ember-animated/easings/linear';

from ember-animated.

I've heard this before, about the index-with-named-exports not being shakable. How is this possible? Seems like the file is easily analyzable from a human perspective... maybe I'm wrong?

from ember-animated.

Modules can have side effects. It's not good style, but it's valid javascript, so a general purpose packaging tool can't just go and break it.

For example, this code is legal, but if you decided nobody was using linear and tried to shake it out, it would break:

// index.js
export { default as linear } from './linear';
export { eastOut, eastIn } from './cosine';

// linear.js
window.easingHelper = function() {};
export default function() {
  ...
  easingHelper();
  ...
}

// cosine.js
export default function() {
  ...
  easingHelper();
  ...
}

(And window is not the only hole, it's impossible to statically detect all the ways state can leak.)

Webpack gets around this by allowing packages to declare themselves side-effect free via their package.json. We can choose to respect that, but it's -- in a small but important way -- deviating from the actual Javascript language.

from ember-animated.

Ah. That makes sense. Thanks for explaining!

from ember-animated.

Is shaking "a thing"? I know it's been talked about for years, but I'm curious if it has an immediate timeline. If not, we could always provide a migration path if/when it gets there.

from ember-animated.

It's already implemented for non-ember-addon packages in ember-auto-import, and it's already implemented for ember packages in embroider.

from ember-animated.

Superseded by #90

from ember-animated.