Currently, adding a file to the addon-test-support directory in an addon allows that file to be exposed and used by a consuming application using the magical test-support/ path. But for some reason I cannot use the same file in the addon’s tests (in the dummy folder). Is there a way for an addon to use its own files in its addon-test-support directory? I’ve tried with the test-support/ path and still doesn’t work.
Also, I would love if someone could explain the magic behind how the addon-test-support directory works, since this doesn’t seem to be officially documented anywhere. Why have addon-test-support directory in the addon, but make it available under test-support/ when using in a consuming application? Wouldn’t it be less confusing to just use addon-test-support/ directory everywhere?
Thanks in advance for any info anyone can provide!
Assuming that you have a file at addon-test-support/blah.js in an addon with a name of foo-bar, you should be able to import from that module via:
import Something from 'foo-bar/test-support/blah';
The idea behind addon-test-support is to allow addons to provide test specific code under its own “namespace” (e.g. within modules with the addons own name) without having to bloat the overall deployed application size.
It is (very poorly) documented here, and I would love help getting these docs more fleshed out.
I’m not sure that I understand the question, can you explain in more detail what you are asking?
I’m interpreting the question as "why do people need to import { something } from "my-addon/test-support" instead of import { something } from "my-addon/addon-test-support".
Which is a legit question. The answer is basically that all these top-level trees in an addon (app, addon, addon-test-support, etc) have specific conventional meanings and get built in specific ways, and none of them actually appear literally in import names.
Thanks @rwjblue for the explanation. I actually figured out that the original issue I was having was due to the file that i was importing. I’ve since fixed it. Thanks!
Yeah, @ef4 you are spot on–that was exactly what I was getting at.
Yeah… this was a little confusing to me when I first began using Ember. I suspect it would be to other newcomers also. Was there any specific technical reasons of why these paths(i.e. addon-test-support) are magically resolved? And is there any thought around possibly changing this behavior? Or at least allowing addon-test-support to be an optional (but preferred) path and leaving the test-support for backwards-compatibility?
The new file system layout (commonly called “module unification”) moves to using src for both apps and addons. In that layout, the src path is not elided from import paths. Once an addon and/or app is migrated to this layout, there will be no “magical” resolver shenanigans and we can embrace “normal JS ecosystem” tooling (e.g. we will be using the standard node resolution mechanisms) for things like linting import paths, bundling, etc.
It is possible to use this layout experimentally now, but still needs some rough edges smoothed out before large scale adoption.