Missing public API imports

[Turbo87]

According to #11 the following list of documented public globals APIs in Ember have no corresponding new module import paths yet:

ContainerProxyMixin
 Ember.FEATURES.isEnabled
Ember.MutableEnumerable
Ember.Namespace
Ember.NativeArray
Ember.Test
Ember.Test.QUnitAdapter
Ember.testing
Ember.VERSION
RouterService
Ember.Handlebars.Utils.escapeExpression
Ember.HTMLBars.template
Ember.Handlebars.compile

user hook:

Ember.onerror

Additionally the ember-cli-shims were exporting the following globals APIs which don't have corresponding new module import paths yet either:

Ember.destroy
Ember.SortableMixin

[webark]

@Gorzas it’s a little more then just a polyfil. (not much more, but a little) That comment does mention that they will “revisit logging” in the future. At first read i read that as more of a suggestion then an answer, but upon reading it more it seems that it’s more of a conclusion. Thanks.

[locks]

Nothing is happening to Ember.Logger until an RFC is filed and accepted.

[elwayman02]

Ember.testing replacement pl0x? 🙏

[BillyRayPreachersSon]

@elwayman02 I've been using the suggestion given by @rwjblue here: https://github.com/emberjs/ember-qunit/issues/297#issuecomment-352408048.

Old:

if (Ember.testing) { ... }

New:

import config from '<projectname>/config/environment';
...
if (config.environment === 'test') { ... }

[rwjblue]

Updating the description for the following:

Ember.ApplicationInstance -> import ApplicationInstance from '@ember/application/instance';
Ember.ApplicationInstance.BootOptions -> Not a "real" class to instantiate
Ember.ComputedProperty -> import ComputedProperty from '@ember/object/computed';
Ember.CoreObject -> import CoreObject from '@ember/object/core';
Ember.Debug.registerDeprecationHandler -> import { registerDeprecationHandler } from '@ember/debug';
Ember.Debug.registerWarnHandler -> import { registerWarnHandler } from '@ember/debug';
Ember.defineProperty -> import { defineProperty } from '@ember/object';
Ember.Engine -> import Engine from '@ember/engine';
Ember.EngineInstance -> import EngineInstance from '@ember/engine/instance';
Ember.Error -> import EmberError from '@ember/error';
Ember.getEngineParent -> import { getEngineParent } from '@ember/engine';
Ember.getWithDefault -> import { getWithDefault } from '@ember/object';
Ember.ObjectProxy -> import ObjectProxy from '@ember/object/proxy';
Ember.Observable -> import Observable from '@ember/object/observable';
Ember.PromiseProxyMixin -> import PromiseProxyMixin from '@ember/object/promise-proxy-mixin';
Ember.Test.Adapter -> import TestAdapter from '@ember/test/adapter';
import TestAdapter from '@ember/test/adapter';

I also removed the following as they were removed in 3.0.0:

Ember.bind
Ember.binding
Ember.K

[btecu]

What about Ember.onerror?

[rwjblue]

After discussion with @tomdale we came up with a bunch of answers (though not completely):

Ember.HTMLBars.template -> import { wrapTemplate } from '@ember/template-compilation';
Ember.HTMLBars.compile -> import { compileTemplate } from '@ember/template-compilation';
Ember.HTMLBars.precompile -> import { precompileTemplate } from '@ember/template-compilation';
Ember.VERSION -> import { VERSION } from '@ember/version';
Ember.onerror -> import { getErrorHandler, setErrorHandler } from '@ember/runloop';
Ember.FEATURES / Ember.FEATURES.isEnabled -> import { FEATURES, isEnabled } from '@ember/canary-features'
Ember.Namespace -> import Namespace from '@ember/application/namespace';

[rwjblue]

@Turbo87 / @Serabe - We will need to come up with some tweaks in the codemod to support assignment (for Ember.onerror)...

[krisselden]

@rwjblue @tomdale I'm very much opposed to this one Ember.HTMLBars.template -> import { wrapTemplate } from '@ember/template-compilation'; it is not a compilation thing, it is a runtime thing for DI. it is not used by the template compiler it is just part of the string of codegen it uses.

[tomdale]

@krisselden The rationale was that we wanted to make it clear that it was an internal helper used as part of codegenned templates, and not something app developers should use. It's not technically used "by" the template compiler, but it is required to evaluate the output the template compiler produces.

If you'd like to put it in a different package than @ember/template-compilation that's fine with me, but I was operating under the assumption that packages could contain both compile-time and run-time code and treeshaking would sort it out appropriately.

[wanxie]

Are Ember-Data modules will be added or is this for Ember only?

[locks]

@wanxie this is for ember.js only, Ember Data is a separate library and needs a separate RFC :)