Infer bundle type (app vs test) by original tree if known.

[rwjblue]

Prior to these changes, we would decide what bundle a given file should end up in based on the modules relativePath that imported it. This worked generally for application level tests that import external packages, as well as for many addon-test-support imports.

Unfortunately, this relative path analysis falls down in addons that intentionally customize their treeForAddonTestSupport so that the addon-test-support/ folder contents are available without the addon-name/test-support suffix. This is done by a number of testing only addons, but the largest offenders are ember-qunit and @ember/test-helpers.

This introduces a new (possibly undefined) value that can be passed into preprocessJs to specify the treeType being transpiled. ember-cli will update to pass this value by default, but any addons doing the sort of overrides mentioned above are likely already doing a manual override and can easily pass in the treeType in their overrides.

Fixes #284

[ef4]

Thanks for working on this. Would this allow an addon to have some files of each kind? I was picturing an API more like:

// my-addon/index.js
module.exports = {
  name: 'my-addon',
  options: {
    autoImport:{
      testsPattern: /\/custom-test-support\//
    }
  }
};

testsPattern would override https://github.com/ef4/ember-auto-import/blob/b558c7c0c53912e03b3f7c7df0e998154cf0cf04/packages/ember-auto-import/ts/bundle-config.ts#L8, but only for this package.

We already track which package goes with each tree that's being analyzed.

[rwjblue]

Would this allow an addon to have some files of each kind?

Ya, if the import is in addon tree those imports would go to assets/vendor.js and if the import is in addon-test-support the imports would end up in the assets/test-support.js bundle.

I was picturing an API more like:

// my-addon/index.js
module.exports = {
  name: 'my-addon',
  options: {
    autoImport:{
      testsPattern: /\/custom-test-support\//
    }
  }
};

Ya, I can do this also as a way to override completely, but I generally would prefer to default to not needing the custom test pattern (and instead infer if a given import should be vendor vs test-support based on the source tree).

[ef4]

Ok, yeah, as long as you're fine requiring the ember-cli change we can stick with that plan and don't need to also introduce the option to override the pattern.

[rwjblue]

Ya, I have a branch with the ember-cli changes required all queued up. However, it is also possible for individual addons to guarantee they are compatible without requiring the ember-cli change.

For example this code in ember-qunit:

  treeForAddonTestSupport(tree) {
    // intentionally not calling _super here
    // so that can have our `import`'s be
    // import { ... } from 'ember-qunit';

    const Funnel = require('broccoli-funnel');

    let scopedInputTree = new Funnel(tree, { destDir: 'ember-qunit' });

    return this.preprocessJs(scopedInputTree, '/', this.name, {
      annotation: `ember-qunit - treeForAddonTestSupport`,
      registry: this.registry,
    });
  },

Will turn into:

  treeForAddonTestSupport(tree) {
    // intentionally not calling _super here
    // so that can have our `import`'s be
    // import { ... } from 'ember-qunit';

    const Funnel = require('broccoli-funnel');

    let scopedInputTree = new Funnel(tree, { destDir: 'ember-qunit' });

    return this.preprocessJs(scopedInputTree, '/', this.name, {
      annotation: `ember-qunit - treeForAddonTestSupport`,
      registry: this.registry,
      treeType: 'addon-test-support'
    });
  },

[rwjblue]

@scalvert helped me track down the cause of the tsc failure, so I think this should pass CI now...

[scalvert]

I think it may be nice to support both testsPattern as a "get out of jail free card", while primarily using treeType. That would allow addons that control the invocation of the preprocessor to use the latter, while giving us an "out" if things go awry.

Nice work on this, @rwjblue.

[rwjblue]

ember-cli/ember-cli#9411 adds the tree type option to all of ember-cli's invocations.

[ef4]

I'm really glad typescript added this feature.

[ef4]

This area deserves extra scrutiny because different versions of ember-auto-import will call each other's copy of analyze. But this looks safe to me -- older copies will not pass the optional argument, newer copies will pass the argument and it will be ignored.