@ember/test-helpers definition

[happycollision]

I mentioned this in Slack, and I figured that I ought to just do it and you can decide here if if works for you.

It adds a blueprint to create a definition for @ember/test-helpers in the types folder. It also adds a line about said file in the readme.

[chriskrycho]

Let's get this on DefinitelyTyped! npm's search doesn't find it, but the package does actually exist.

[dfreeman]

For what it's worth, the typings exist in the npm registry too 😉
https://www.npmjs.com/package/@types/ember__test-helpers

[happycollision]

Okay. So the way that npm does search and the way DT does search ember__test-helpers missing from TypeSearch means that people who don't know the idiosyncratic nature of a given package means that they cannot find it as easily...

Learning.

I'll adjust this PR to add the @types/ember__test-helpers to dependencies.

[happycollision]

I am not sure that this is the best way to describe what is going on here. Because... I do not actually know what is going on here. Since this all comes from the same package that is already typed a few lines up above, I don't know why we need this definition, too. Shouldn't the other one declare both modules?

[dfreeman]

There are a couple factors in play. One is that tools like VS Code can use import paths to provide intelligent typeahead and documentation even in plain JS files, but the apparent package name in the path needs to match up with the published @types package for that to work.

The other is that ember-test-helpers is actually no longer getting new releases — it's being published as @ember/test-helpers now, and that re-exports some old stuff (that's slated for deprecation, I believe) along with all the new helpers under the old ember-test-helpers namespace. Eventually, @ember/test-helpers will be the only thing left.

I think we probably want to move toward not adding @types/ember-test-helpers or @types/ember-testing-helpers to new projects, but that can happen as follow on work.

[happycollision]

I am not sure why this isn't passing... though I only looked for a line that I thought was correct and added another one.

But I think this should actually do it, @chriskrycho.

[dfreeman]

Thanks @happycollision!

The previous failure looks like it was just a hiccup (albeit one in some fairly new testing infrastructure we have, so we should definitely keep a close eye on it in the future)

Okay. So the way that npm does search and the way DT does search ember__test-helpers missing from TypeSearch means that people who don't know the idiosyncratic nature of a given package means that they cannot find it as easily...

I actually didn't even know TypeSearch was a thing, but I see a number of open issues complaining that its behavior is weird and things seem to be missing.

Agreed that the naming scheme for scoped packages is odd and hard to discover, but it's a tricky scenario trying to invent a way to have a double-scoped package name. I'm not sure what layer of the tooling this comes from, but my editor at least suggests what @types package I should look for when it can't find declarations: