First up -thanks to everyone who helps maintain this amazing project! I've been blessed to see our community rally around ember-cli since the pre EAK days and couldn't be more productive day to day as a result!

After some discussion w/ Matt yesterday I decided it was time to get serious about providing feedback for Module Unification. The primary lens I'm using to look at this today is that of an existing ember redux consumer who wants to adopt the new filesystem layout (module unification).

To start, I installed ember-cli/ember-cli and from that I created an ember app w/ MODULE_UNIFICATION=true as mentioned in the FINAL CUT issue.

MODULE_UNIFICATION=true ember new watt

Next, I installed the current stable addon for ember redux again w/ MODULE_UNIFICATION=true as mentioned in the FINAL CUT issue for MU.

MODULE_UNIFICATION=true ember install ember-redux

What I found is that the ember redux addon service expects to find a file in the top level src directory for reducers as shown below.

// app/services/redux.js

import ReduxService from 'ember-redux/services/redux';
import reducers from '../reducers/index';
import enhancers from '../enhancers/index';
import middlewares from '../middleware/index';

export default ReduxService.extend({ reducers, enhancers, middlewares });

The example app I put together this morning does produce a module w/ the key `watt/src/reducers/index' (in watt.js under dist/assets) but unlike ember-cli (stable) the addon doesn't allow the consuming app to override it.

note: when I use require directly inside the function that creates the redux store and pull in the reducers/index.js from my src/reducers/ directory the app works fine :)

var xyz = require('watt/src/reducers/index').default;

^aside about "why" ember redux took this approach.

When I wrote the ember redux addon years ago I wanted to provide sensible "defaults" for middleware, reducers and enhancers so I could configure the redux store without any work on behalf of the developer. At the same time I wanted to unlock the ability for developers to override middleware and enhancers when they grow beyond the happy path (ie: when they decide to use generators/or RxJS for side effects as 1 example).

If I understand the MU RFC it seems to me that addons won't have both addon & app directories (like we do today) allowing the consuming app to override on demand.

*aside about direct imports vs using the resolver

I did speak briefly w/ Robert Jackson a while back about this services file (because of my direct imports) and wanted to mention that I'm intentionally avoiding the ember resolver here. In ember redux we don't tie into the resolver like you find w/ routes and components because reducers/middleware/enhancers are just functions (not objects). This hasn't been a problem for day to day development but may now be something we need to discuss further (open to options here if anyone has suggestions that will help us avoid a breaking change for consumers of the addon/ ember-cli vNow and vNext).

Clarification:

Is this behavior I've discovered considered a breaking change?

Question:

How should I provide sensible defaults like this for ember-cli generated apps that use module unification?

Output from ember version --verbose && npm --version && yarn --version:

ember-cli: 3.1.0-beta.1
http_parser: 2.7.0
node: 8.9.4
v8: 6.1.534.50
uv: 1.15.0
zlib: 1.2.11
ares: 1.10.1-DEV
modules: 57
nghttp2: 1.25.0
openssl: 1.0.2n
icu: 59.1
unicode: 9.0
cldr: 31.0.1
tz: 2017b
os: darwin x64
5.6.0
1.5.1