Add test for v2 addon importing from v1 addon's fake module

[NullVoxPopuli]

This added test is to try to recreate some troubles I've been experiencing with

• chore(internal, tests): correctly configure maybeEmbroider NullVoxPopuli/ember-resources#279
• which has related issue: Cannot import from @glimmer/tracking/primitives/cache #1020

The end goal is to reproduce the problem in embroider's test suite, so I can debug what's going on a little easier.

[ef4]

Either way this will be good to keep in the test suite.

[ef4]

I think your original bug may have been around @glimmer/component, which is definitely different from the other "fake" ember packages because a real package does exist, but the implementation inside it is really only for standalone glimmerX and shouldn't actually be used, because Ember contains the real implementation.

[NullVoxPopuli]

I think your original bug may have been around @glimmer/component

yeah, I have a couple things I'm trying to reproduce:

from here: https://github.com/NullVoxPopuli/ember-addon-v2-typescript-demo
@glimmer/component appears to be undefined.

from here: NullVoxPopuli/ember-resources#366

• this issue: Cannot import from @glimmer/tracking/primitives/cache #1020

[josemarluedke]

I was playing with ember-addon-v2-typescript-demo and figured out that @glimmer/component is returning an object with default instead of the component class.

See:

When logging Component, we can see it as an object:

If I change the dist files to class FlatDemo extends Component.default, that works.

EDIT: That setup was not using embroider actually, just ember-auto-import.

[ef4]

The problem in that demo repo is:

https://github.com/NullVoxPopuli/ember-addon-v2-typescript-demo/blob/125700fc9aa77faec4d9a49c514a4fa90e477996/my-addon/package.json#L10

When webpack sees that it gets Very Strict with your module, including disabling things like interoperability between import and require.

But we need the interoperability, because in a classic build (which is what that repo is using), @glimmer/component has long since been transpiled from an ES module to AMD by the time our v2 addon gets it. Without the interop, we don't know to grab the .default property off the value that comes back from require().

Under Embroider things are different, because webpack will see @glimmer/component as a real ES module. But the build fails in that case for other reasons. I'm not really sure if we can turn on this level of Webpack strictness until much more of Ember itself ships as ES modules. We liberally use require() in the compiled output to paper over the gap between Ember's runtime loader and ES module loading.

[ef4]

I think you can use Rule.type to override webpack's behavior here and go back from javascript/esm to javascript/auto.

[NullVoxPopuli]

ah, interesting -- I hadn't heard of rule.type before.

Changing my config in the test app to this has everything working with @josemarluedke's addon-dev changes. 🎉

updated emebr-cli-build.js

'use strict';

const EmberApp = require('ember-cli/lib/broccoli/ember-app');

module.exports = function (defaults) {
  let app = new EmberApp(defaults, {
    autoImport: {
      watchDependencies: [Object.keys(require('./package').dependencies)],
      webpack: {
        devtool: 'inline-source-map',
        module: {
          rules: [{ test: /\.(js|ts)$/, type: 'javascript/auto' }],
        },
      },
    },
  });

  const { maybeEmbroider } = require('@embroider/test-setup');

  return maybeEmbroider(app, {
    packagerOptions: {
      webpackConfig: {
        devtool: 'inline-source-map',
        module: {
          rules: [{ test: /\.(js|ts)$/, type: 'javascript/auto' }],
        },
      },
    },
  });
};

Some followup questions though -- and maybe "elsewhere" is more appropriate for this sort of discussion, but idk:

Without the interop, we don't know to grab the .default property off the value that comes back from require().

does the problem go away if we convert @glimmer/component to a v2 addon? (I know that's not easy and has a lot of nuance right now, since all the implementations of stuff are actually in glimmer -- but just conceptually -- is it the whole ecosystem that needs this sort of interop? or just the @glimmer/* stuff?

I'm not really sure if we can turn on this level of Webpack strictness until much more of Ember itself ships as ES modules. We liberally use require() in the compiled output to paper over the gap between Ember's runtime loader and ES module loading.

does a PR to flip to the defaults to javascript/auto in both auto-import and embroider make sense? (at least until more native ES Modules are shipped? (also, does this mean it's more than just @glimmer/* that has some special interop? (I suppose the template-compiler?)))