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:
Easy steps to reproduce:
volta install ember-cli ember new --embroider my-cool-app cd my-cool-app ember sNow visit http://localhost:4200
You will see a blank screen, and if you open the browser console you will see:
Specifically, it appears that
Storehere is undefined. Further investigation ember-data's-privatemodule appears to be rolled up into some AMD modules: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
treeForAddonrollup behavior via it'sEMBER_DATA_ROLLUP_PRIVATEenvironment variable does not solve our problem, as those ember-data has internal paths that cannot be resolved.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 processingstore/-private.jsas 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/-privatefile: