chore(all): convert to TS

[bigopon]

Beside conversion, also add ability to configure Compose behavior to not inherit binding context by default via entry configure function:

export function configure(config: any, { useLegacyBehavior = true } = {}); {
  Compose.useLegacyBehavior = useLegacyBehavior;
}

It's based on @jdanyow 's comment here #222 (comment)

Though I'm not sure when Compose is configured to not inherit binding context, it should throw or just silently inherit when composed with view only instruction.

Besides that, adjust build, so now distribution will be a single file with sourcemap enabled. Something like this

@EisenbergEffect @jdanyow @jods4 @fkleuver

@fkleuver What should i adjust circle CI of this to?

@huochunpeng
resolves #332
resolves #300
resolves #321

[EisenbergEffect]

Wow! @bigopon You are a beast! This is awesome. How should we proceed. I'm not sure if I have a ton of time to review every line. I trust your work though :) Is there anything in particular we should look at, any concerns, details left to polish up?

[bigopon]

@EisenbergEffect The plan is like this:

in templating-router and templating-resources, accept 2nd paramter for configure function to toggle legacy behavior for Compose and RouterView.

in framework, add method enableLegacyBehavior(enabled: boolean) to FrameworkConfiguration to pass that to those two modules.

Write some doc for this.

Details to look at:

There are two way to toggle Compose behavior:

• at start up time: like explained above
• at any time: Compose.useLegacyBehavior = true/false (default is true for compat). I'm not sure about naming.

[bigopon]

About the conversion, it's not that much of a big deal I think. Most typings are still kept any for safety reasons. Mostly it's the build/tests/development flow that are cleaner now

[EisenbergEffect]

@bigopon Instead of using the generic terms "legacy behavior" can we instead make the property name more explicit in what it's doing? For example allowParentScopeTraversal = true or something like that. Not sure exactly what the name would be.

[bigopon]

@EisenbergEffect that sounds good to me. Will need to adjust router view accordingly. What about view only composition, do we want to auto traverse parent, or throw?

[EisenbergEffect]

For view-only composition, remind me what happens with the binding context. Does it get nothing if it doesn't traverse? That doesn't seem right. Is there a reason we would treat this scenario differently?

[bigopon]

It points to the Compose element with its overrideContext https://github.com/aurelia/templating-resources/blob/6aa889b2f8aa92ca6a9b8acb3a0ba4bdca7372d7/src/compose.ts#L227L228

Which I think it will automatically inherit owning view of compose by default. So only need some tests, no need to change anything here

[EisenbergEffect]

If it inherits the owning view, that sounds ideal.

[bigopon]

@EisenbergEffect here are the two skipped tests

• https://github.com/aurelia/templating-resources/pull/374/files/6aa889b2f8aa92ca6a9b8acb3a0ba4bdca7372d7..5347777153b3ee4b8b90a63fe570d72910827f8f#diff-342077e7f5694040ec714108a9a1234aR134
• https://github.com/aurelia/templating-resources/pull/374/files/6aa889b2f8aa92ca6a9b8acb3a0ba4bdca7372d7..5347777153b3ee4b8b90a63fe570d72910827f8f#diff-342077e7f5694040ec714108a9a1234aR150

I just realized when adding some integration tests for compose, that <router-view/> and <compose/> do composition differently. <router-view/> controls the behavior instruction, while <compose/> does not.

For this, I think I'll have to add something in templating.

[EisenbergEffect]

@bigopon I'd rather just delete the code than comment it out usually. Was there a strong argument for doing it this way?

[bigopon]

@EisenbergEffect Removed

[bigopon]

@EisenbergEffect one of throttle tests is failing, its' probably non-deterministic timing related, we can fix that later.