Avoid mutating module exports. #114
Comments
|
This has reared its ugly head again. See description in mike-north/ember-lodash#104. We need to move forward and kill |
|
@rwjblue I'm happy to take this on. We (Square) are finally migrating to Ember CLI and we're trying to switch out our custom module runtime with loader.js ahead of time to discover any subtle incompatibilities. The cyclical One question: What do you mean by "debug build"? Unless I'm missing something, there's only a prod build (dist/loader/loader.js) and an instrumented build (dist/loader/loader.instrument.js). Do we need to update The benchmarks load the instrumented or prod build conditionally, but I'm not seeing the instrumented build referenced elsewhere. Thanks! |
|
Ack: I just noticed the ember-addon code in index.js. I think I know how to proceed. But if you have any similar debug builds I could model this after, please let me know! |
|
This library is now an ember-cli addon, we directly app.import the specific transpiled dist file that we need. We have a build script that we use to generate those pre-built assets. Rough steps:
Happy to discuss further, feel free to ping me here or in the community slack... |
Before updating the build system to support stripping debug code, we need to upgrade to babel6. Prep work for ember-cli#114
Upgrading to babel6 allows us to use the babel-plugin-debug-macros plugin in a future change. Prep work for ember-cli#114
Upgrading to babel6 allows us to use the babel-plugin-debug-macros plugin in a future change. Prep work for ember-cli#114
Upgrading to babel6 allows us to use the babel-plugin-debug-macros plugin in a future change. Prep work for ember-cli#114
Upgrading to babel6 allows us to use the babel-plugin-debug-macros plugin in a future change. Prep work for ember-cli#114
Upgrading to babel6 allows us to use the babel-plugin-debug-macros plugin in a future change. Prep work for ember-cli#114
…lt` exports If a module does not define a default export, loader.js assigns `exports.default = exports` for compatibility with modules that don't use `_interopRequireDefault` from babel6. Mutating exports is unexpected behavior and causes difficult-to-diagnose [bugs][1]. We should remove `makeDefaultExport` in version 5.0. This update * adds a deprecation warning in preparation for removing `makeDefaultExport`. * adds a debug build with the deprecation enabled. Addresses ember-cli#114 [1]:mike-north/ember-lodash#104
…lt` exports If a module does not define a default export, loader.js assigns `exports.default = exports` for compatibility with modules that don't use `_interopRequireDefault` from babel6. Mutating exports is unexpected behavior and causes difficult-to-diagnose [bugs][1]. We should remove `makeDefaultExport` in version 5.0. This update * adds a deprecation warning in preparation for removing `makeDefaultExport`. * adds a debug build with the deprecation enabled. Addresses ember-cli#114 [1]:mike-north/ember-lodash#104
…lt` exports If a module does not define a default export, loader.js assigns `exports.default = exports` for compatibility with modules that don't use `_interopRequireDefault` from babel6. Mutating exports is unexpected behavior and causes difficult-to-diagnose [bugs][1]. We should remove `makeDefaultExport` in version 5.0. This update * adds a deprecation warning in preparation for removing `makeDefaultExport`. * adds a debug build with the deprecation enabled. Addresses ember-cli#114 [1]:mike-north/ember-lodash#104
…lt` exports If a module does not define a default export, loader.js assigns `exports.default = exports` for compatibility with modules that don't use `_interopRequireDefault` from babel6. Mutating exports is unexpected behavior and causes difficult-to-diagnose [bugs][1]. We should remove `makeDefaultExport` in version 5.0. This update * adds a deprecation warning in preparation for removing `makeDefaultExport`. * adds a debug build with the deprecation enabled. Addresses ember-cli#114 [1]:mike-north/ember-lodash#104
Modules that return an object or only declare named exports are no longer mutated to include a `default` export. Addresses ember-cli#114 Breaking change: loader.js will no longer create a default export.
…port This property allows for an immediate option to remove the functionality that mutates the module exports (ember-cli#114) and allows for a deprecation cycle when maintainers are ready to do so Workaround for ember-cli#114
…lt` exports If a module does not define a default export, loader.js assigns `exports.default = exports` for compatibility with modules that don't use `_interopRequireDefault` from babel6. Mutating exports is unexpected behavior and causes difficult-to-diagnose [bugs][1]. We should remove `makeDefaultExport` in version 5.0. This update * adds a deprecation warning in preparation for removing `makeDefaultExport`. * adds a debug build with the deprecation enabled. Addresses ember-cli#114 [1]:mike-north/ember-lodash#104
We should stop mutating the modules exports.
This was needed while ember-cli was using
amdStrictmode (since it did not use the_interopRequireDefaultbabel helper), and that is being unrolled in ember-cli/ember-cli#6827.Suggested migration path is:
Object.defineProperty(exports, 'default,...)with a getter that issues a deprecation warning in debug builds (avoidingObject.definePropertyin prod builds).The text was updated successfully, but these errors were encountered: