[fixes #2723 #2813] opt-out flag for slash being the namespace separator.

[stefanpenner]

(cc @kselden)

[stefanpenner]

i suppose i should use feature instead of ENV flag... thoughts?

[hjdivad]

@stefanpenner I presume feature flags are things that would one day go away once the feature makes it into a release. This seems different from runtime config flags.

[wagenet]

@stefanpenner I recall @wycats having doubts about long running flags like this. Is this an exceptional case?

[stefanpenner]

@wagenet i'm unsure what the other option is, unless we want to break backwards compat, or have more hacks. I am very open to suggestions.

The current namespace solution is basically broken, but people may depend on it. As it is broken, and we have a successor planned, we would like to eventually phase it out. Most of the complexity is within the resolver, but that render helper hack leaks complexity all over the place.

[wagenet]

@stefanpenner We should discuss this at the core team meeting tomorrow.

[stefanpenner]

lets add this to this upcoming meeting, as I was sick and missed the last one.

[stefanpenner]

I should likely wrap this up in some more DefaultResolver + normalization improvements.

[wagenet]

@stefanpenner status?

[stefanpenner]

@wagenet you had concerns about long running flags, what is your current thought on that.

This slash as namespace is actually quite broken. I would love to know how many people use it, or rely on it.

[stefanpenner]

note to self, should try to extract this into the resolver.

[rwjblue]

I believe that this is likely a good case (see #3936 for another example) for feature flags in the stable build. By flagging this change, and leaving the value null in features.json consumers could opt-out of the slash-as-namespace issue all together.

[limptwiglet]

Just wondering if there has been any more thoughts on this as its causing problems for myself.

[wagenet]

@stefanpnner status? If this isn't resolved, can we put this on the agenda @rjackson?

[stefanpenner]

resolution @rjackson and @stefanpenner will propose an upgrade path.

[rwjblue]

My suggested path is:

• Detect usage of / and print deprecation warning. This would end up in 1.6.0.
• Add feature flag (ember-routing-use-deprecated-slash-namespacing) that does the following (to be enabled by default in 1.7):
  • If 'true' (aka enabled), detect usage of '/', print deprecation warning and use old (current) behavior
  • If 'false' (aka disabled), do not replace / with ., no warnings/errors.
• Change default value of feature flag. Making the old behavior opt-in. For 1.8.
• Remove flag completed? 1.9?

@stefanpenner - +1/-1?

[stefanpenner]

@rjackson I think @wycats would prefer no flag, just a hard deprecation.

[rwjblue]

OK, assuming no flagging, then the plan would be:

• Detect usage of / and print deprecation warning, still do old behavior. This would end up in 1.6.0.
• Detect usage of / and print deprecation warning, do not do old behavior. This would end up in 1.7.0.
• Remove deprecation. 1.8.0.

@stefanpenner - Sound right?

[stefanpenner]

@rjackson yes.
We should do another quick pass of other places where we enforce such hacks, but should be the responsibility of the resolver.

[stefanpenner]

this also basically deprecates an early attempt at namespaces

[stefanpenner]

likely related:

• https://github.com/emberjs/ember.js/blob/master/packages/ember-routing/lib/system/route.js#L1436
• https://github.com/emberjs/ember.js/blob/master/packages/ember-routing-handlebars/lib/helpers/render.js#L114
• https://github.com/emberjs/ember.js/blob/master/packages/ember-routing/lib/system/route.js#L1518
• https://github.com/emberjs/ember.js/blob/master/packages/ember-routing/lib/system/route.js#L1847

cc @lukemelia

[wagenet]

See #5260

[stefanpenner]

i'll start the deprecation process tonight

[stefanpenner]

we are going to deprecate, this PR wil not be needed.