Error: Can't resolve 'ease'

[willhoag]

Pulled in all component dependencies in order to maintain a non-breaking status. Could use a rewrite with a bump to v3.0.0, but this makes sense as a first step.

Original Issue via @coreyward

Similar issue to #5, only this time with the component-tween dependency. Honestly, it's turtles all the way down; the component/___ libraries were really only meant to work for Component, which is now deprecated and no longer maintained.

It may make sense to switch to another tween library, like Tween.js, but it could also be fairly simple to hardcode the minimum viable code and eliminate deps altogether.

[coreyward]

This resolves the errors for me!

If you wanted to cut down on extraneous code it would be trivial to drop the unused timing functions, but I suspect the build process will do it anyways.

[willhoag]

The ease functions are part of the API as you can choose the ease in the options object.

Q: Any thoughts on how I should version this? You can make an argument for Major, Minor and Patch for codebases that happen to utilize component/s since this increases the size a non-trivial amount.

[coreyward]

Re: easing — I missed the options and just saw out-circ. 👍

Re: versioning — does this introduce any functional changes or would you consider it strictly a bugfix? If no functional changes, it's a patch. If there are functional changes, but they're backwards compatible, it's a minor version change. I suspect it's the former.

[willhoag]

That's how I usually treat versioning. Thinking it really depends on if you treat codesize as a functional feature of a module I guess. Do you know if Semver has an official stance on that?

[coreyward]

Size isn’t functional, unless it impacts something else. It’s an implementation detail really.

[willhoag]

My thinking was that size isn't strictly an implementation detail as it affects load times, hard limits on less than capable devices etc. but in this case, it isn't egregiously larger ...so, I suppose I'll treat it as a patch. Thx. 👍