Deprecations will fire spuriously under strict ES module builds about data

[runspired]

Historically Ember has allowed "modules" to remain un-evaluated until they are synchronously required. That is not possible under true ES modules.

This sounds like a bundler error then, not a spec error so I wouldn't phrase it as "under true ES modules". By spec, a module should not even be loaded until a module which requires it is evaluated, and so a spec compliant bundler would in fact not eagerly evaluate the module unless accessing a specific entry point ultimately led to accessing the file.

As regards EmberData, overall I'm incline to believe we shouldn't do anything different here. We ship native ESM modules and we aren't what is responsible for causing those to be pushed into the build automatically. Transforms get pushed in because our tooling historically assumes that all code in the app directory needs to be pushed in, and because transforms are usually used via ember's resolver and so need to be there synchronously (they don't have to be used that way fwiw).

With this said, if you get this deprecation then almost by definition you should get this deprecation, because even if you don't think you are using these transforms you are and should go ahead and make their inclusion public, else drop ember-data as a dep and consume the individual packages so that they aren't guaranteed to be available to the resolver.

If any files print this that aren't the transforms, I'll reopen this to pursue a pragmatic fix.

[ef4]

By spec, a module should not even be loaded until a module which requires it is evaluated

Yes, but "requires" is an imprecise word here. What you mean is "imports it", because importing a module is the only legal way to depend on it. And ember-data doesn't ever import the transforms, which is the only reason we're having this discussion.

ember-data is going to do getOwner(this).lookup('transform:boolean') an expect to synchronously get back the contents of the ES module. That absolutely means that the module must have already been evaluated earlier, because there's no way to synchronously evaluate an ES module that wasn't already evaluated.

[runspired]

ember-data is going to do getOwner(this).lookup('transform:boolean') an expect to synchronously get back the contents of the ES module

nit: a specific serializer we currently provide does do this though we consider it to be app code if an app makes use of it. Most of the time, it will be app code that does the resolver lookup. EmberData itself makes no use of Ember's resolver outside of adapterFor and serializerFor, both of which are also optional hooks and can be easily implemented to not use the resolver.

[runspired]

My general takeaway is the transform deprecation printing in this situation is desirable and not spurious, it just alerts the user to a requirement they may not have been paying attention to. If they truly don't want the code, then it might be time to consider bringing less of EmberData :D