Current incompatibly with ember-data

[stefanpenner]

Easy steps to reproduce:

volta install ember-cli
ember new --embroider my-cool-app
cd my-cool-app
ember s

Now visit http://localhost:4200

You will see a blank screen, and if you open the browser console you will see:

setup.js:20 Uncaught TypeError: Cannot read property 'prototype' of undefined
    at eval (setup.js:20)
    at Object../node_modules/@ember-data/debug/setup.js (chunk.06d7dffe9041939b9f13.js:116)
    at __webpack_require__ (chunk.b0e67822b39af2a49fc0.js:31)
    at eval (ember-data-data-adapter.js:5)
    at Object../initializers/ember-data-data-adapter.js (chunk.dd0fea93c6e08f487166.js:182)
    at __webpack_require__ (chunk.b0e67822b39af2a49fc0.js:31)
    at Module.eval [as callback] (t-e.js:25)
    at Module.exports (loader.js:106)
    at requireModule (loader.js:27)
    at resolveInitializer (index.js:10)

Specifically, it appears that Store here is undefined. Further investigation ember-data's -private module appears to be rolled up into some AMD modules:

window.define("@ember-data/record-data/-private", function () {
  return _record_data_private_js__WEBPACK_IMPORTED_MODULE_0__;
});
define("./-private", ['exports', "ember-source/@ember/application/index.js", "ember-source/@ember/debug/index.js", "ember-source/@ember/error/index.js", "ember-source/@ember/object/index.js", "ember-source/@ember/polyfills/index.js", "ember-source/@ember/utils/index.js", "ember-source/@ember/array/index.js", "ember-source/@ember/runloop/index.js", "ember-source/@ember/service/index.js", "ember-source/@ember/test/index.js", "ember-source/ember/index.js", 'require', "ember-source/rsvp/index.js", "ember-source/@ember/string/index.js", "ember-source/@ember/array/proxy.js", "ember-source/@ember/object/computed.js", "ember-source/@ember/object/promise-proxy-mixin.js", "ember-source/@ember/object/proxy.js", "ember-source/@ember/object/evented.js", "ember-source/@ember/object/mixin.js", "./-debug"], function (exports, application, debug, EmberError, object, polyfills, utils, EmberArray, runloop, Service, test, Ember, require$1, RSVP, string, ArrayProxy, computed, PromiseProxyMixin, ObjectProxy, Evented, Mixin, Debug) {
  'use strict';

This is unexpected, given that I believe embroider attempts to turns off this capability of ember-data. Debugging though reveal that ember-data's treeForAddon does indeed still run. This suggests a potential issue with embroider's ember-data compatibility adapter (or embroiders general ability to disable some addon trees). (note: I will refer to this as bug number 1).

Unfortunately, the problems don't end here. Disabling ember-data's treeForAddon rollup behavior via it's EMBER_DATA_ROLLUP_PRIVATE environment variable does not solve our problem, as those ember-data has internal paths that cannot be resolved.

Module not found: Error: Can't resolve '../node_modules/@ember-data/model/-private.js' in '$TMPDIR/embroider/23111c/assets/t-e.js'

At this point, I was a little confused. How was this ever working? My guess is that for a while, embroider's ember-data campability addon did correctly skip ember-data's treeForAddon hook, and worked correctly. Basically, it appears that although embroider thought it was disabling ember-data's rollup build, it was in-fact webpack ability to assimilate AMD was bridging the gap. simply processing store/-private.js as an es6 module.

So what happened? The following ember-data commit appears to be what broke the camels back. After this commit, ember-data's file was converted into AMD by the time webpack looked at it, which caused some issues. I was under the impression that webpack handled this case, but I'll dig in...

output from passing/failing variants of the @ember-data/store/-private file:

[stefanpenner]

Update: I believe ember-data no longer correctly respects shouldCompileModules option, causing the problem.

[Proposed Fix] -> The following PR to ember-data fixes the issue locally for both classic and embroider builds emberjs/data#7680

[stefanpenner]

@ef4 I am surprised embroider's tests don't catch this. I suspect we are missing some coverage. Especially if a compat adapter isn't working as expected.

[stefanpenner]

I was using an older version of embroider in my tests. As of embroider@0.43.3 the problem is resolved. That being said, ember-data should respect the flag in question.... I will ensure my PR lands there, but this issue can be treated as resolved.