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

[locks]

Ember.K is deprecated, don't think it should be included?

[Turbo87]

good point, I didn't check the deprecated flag on those 😞

[rwjblue]

Ember.Binding and Ember.bind are also deprecated I believe.

[rwjblue]

Ember.onerror is a user provideable hook (not something that Ember itself provides).

[rwjblue]

Ember.registerDeprecationHandler
Ember.registerWarnHandler

These are both wrong, they should be Ember.Debug.register*. The docs may need updating (since I know that is where you generated this list from).

[rwjblue]

I didn't think that we exposed the RouterService on the global at all actually. We make it available in the default app registry, but I don't think we actually set a Ember.RouterService (we'll have to confirm).

[Turbo87]

I've updated the list

I didn't think that we exposed the RouterService on the global at all actually. We make it available in the default app registry, but I don't think we actually set a Ember.RouterService (we'll have to confirm).

that's probably why it's not prefixed with Ember.

[cibernox]

@Turbo87 @rwjblue This is the list of public APIs without an import path in the new modules. However, some of those public API might be deprecated.

Is the intention of the RFC to expose all the public APIs as modules, regardless of their deprecation state, or those should not be included?

[rwjblue]

Is the intention of the RFC to expose all the public APIs as modules, regardless of their deprecation state, or those should not be included?

I think it would need to be a case by case basis on the deprecated items. For example, I don't think K makes much sense (and you have already written a codemod for it).

[locks]

@rwjblue #12 (comment) up for review:

• deprecation https://github.com/emberjs/ember.js/pull/15456/files
• warn https://github.com/emberjs/ember.js/pull/15457/files

[rwjblue]

Added Ember.defineProperty to the list.

[cibernox]

Proposals that try to follow the guidelines in the RFC.

Before	After
Ember.ApplicationInstance	import ApplicationInstance from "@ember/application-instance"
Ember.ApplicationInstance.BootOptions	Is this public API?
Ember.ComputedProperty	import ComputedProperty from "@ember/object/computed"
Ember.CoreObject	import CoreObject from "@ember/object/core"
Ember.Debug	Not exported, it's just a namespace
Ember.Debug.registerDeprecationHandler	import { registerDeprecationHandler } from "@ember/debug"
Ember.Debug.registerWarnHandler	import { registerWarnHandler } from "@ember/debug"
Ember.defineProperty	No clue
Ember.Engine	import Engine from "@ember/engine"
Ember.EngineInstance	import Engine from "@ember/engine-instance"
Ember.Error	import Error from "@ember/error"
Ember.FEATURES.isEnabled	import { isEnabled } from "@ember/features";
Ember.getEngineParent	import { getEngineParent } from "@ember/engine"
Ember.getWithDefault	import { getWithDefault } from "@ember/object"
Ember.MutableEnumerable	import MutableEnumerable from "@ember/mutable-enumerable
Ember.Namespace	import Namespace from "@ember/object/namespace"
Ember.NativeArray	Is there any reason for this to be public? Isn't this only used to extend the prototype of Array?
Ember.ObjectProxy	@import ObjectProxy from "@ember/object-proxy"
Ember.Observable	@import Observable from "@ember/object/observable"
Ember.PromiseProxyMixin	@import PromiseProxyMixin from "@ember/promise-proxy-mixin"; (meh)
Ember.Test	Not exported, just a namespace
Ember.Test.Adapter	@import TestAdapter from "@ember/test/adapter"
Ember.Test.QUnitAdapter	@import TestAdapter from "@ember/test/qunit-adapter" (Is this part of Ember? Shouldn't it be on an addon)
Ember.testing	Unsure
Ember.VERSION	import VERSION from "@ember/version" (this kind of breaks the rules of default exports being classes)
RouterService	Unsure

Close seconds:

Before	After
Ember.ApplicationInstance	import ApplicationInstance from "@ember/application/instance"
Ember.EngineInstance	import EngineInstance from "@ember/engine/instance"

[rwjblue]

We discussed this issue at todays Ember core team meeting, and have generally agreed to your list above with the following (relatively small) modifications:

// some that you were unsure of
import { isTesting, setTesting } from '@ember/test'; // Ember.testing
import { defineProperty } from '@ember/object'; // Ember.defineProperty

// we preferred alternates for these:
import ApplicationInstance from "@ember/application/instance";
import EngineInstance from "@ember/engine/instance";
import PromiseProxyMixin from "@ember/object/promise-proxy-mixin";
import ObjectProxy from "@ember/object/proxy"

// we want to hold off on these for now (will review again next week):
Ember.VERSION
Ember.Test.QUnitAdapter // as of QUnit 2.0 this is completely provided by ember-qunit

Would love a PR adding the missing things, then we can update the listing in the description...

[Turbo87]

instead of import MutableEnumerable from "@ember/mutable-enumerable" I would like to suggest import MutableEnumerable from "@ember/enumerable/mutable"

[cibernox]

Updated table with suggested changes:

Before	After
Ember.ApplicationInstance	import ApplicationInstance from "@ember/application/instance"
Ember.ApplicationInstance.BootOptions	Is this public API?
Ember.ComputedProperty	import ComputedProperty from "@ember/object/computed"
Ember.CoreObject	import CoreObject from "@ember/object/core"
Ember.Debug	Not exported, it's just a namespace
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 Engine from "@ember/engine/instance"
Ember.Error	import Error from "@ember/error"
Ember.FEATURES.isEnabled	import { isEnabled } from "@ember/features";
Ember.getEngineParent	import { getEngineParent } from "@ember/engine"
Ember.getWithDefault	import { getWithDefault } from "@ember/object"
Ember.MutableEnumerable	import MutableEnumerable from "@ember/mutable-enumerable
Ember.Namespace	import Namespace from "@ember/object/namespace"
Ember.NativeArray	Is there any reason for this to be public? Isn't this only used to extend the prototype of Array?
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"; (meh)
Ember.Test	Not exported, just a namespace
Ember.Test.Adapter	@import TestAdapter from "@ember/test/adapter"
Ember.Test.QUnitAdapter	(Is this part of Ember? Shouldn't it be on an addon?)
Ember.testing	import { isTesting, setTesting } from "@ember/test"
Ember.VERSION	import VERSION from "@ember/version" (this kind of breaks the rules of default exports being classes)
RouterService	Unsure

[rwjblue]

Now that some of these have been landed, we should update the list in the description...

[cibernox]

@Turbo87 Can you edit the table and remove what was implemented? Heading off right now.

[cibernox]

I found another missing API: Ember.Test.registerAsyncHelper

[cibernox]

Missing API imports and they suggested import paths

Before	After
Ember.Test.registerAsyncHelper	@import { registerAsyncHelper } from '@ember/test
Ember.Test.registerHelper	@import { registerHelper } from '@ember/test
Ember.Test.registerWaiter	@import { registerWaiter } from '@ember/test
Ember.Test.unregisterHelper	@import { unregisterHelper } from '@ember/test (what is the use case for this?)
Ember.Test.unregisterWaiter	@import { unregisterWaiter } from '@ember/test (what is the use case for this?)

If there is agreement I could PR that tonight or tomorrow.

[benwalder]

We are using 2.16, where import { isTesting, setTesting } from '@ember/test' does not work. We still need to use Ember.testing. Any thoughts on this?

What is the path forward with import { isTesting, setTesting } from '@ember/test';?
This doesn't seem like something that can be defined using just the json manifest.

[GCheung55]

Looks like Ember.Copyable is missing as well.

[locks]

@GCheung55 that is private API

[GCheung55]

@locks you’re right. My mistake.

[locks]

no problem, thanks for keeping an eye out!

[webark]

Was there ever a definitive answer for if we are going to include Logger, or if it's getting depreciated/removed?

[Gorzas]

@webark It seems that's going to be removed, Ember.Logger is no more than a polyfill as it was said at emberjs/rfcs#176

[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: emberjs/ember-qunit#297 (comment).

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 :)