Updates publish step to publish JavaScript + *.d.ts vs. .ts files.

[stefanpenner]

Fixes #290

This moves the ember-cli-typescript to a dev dependency, and does not require the consuming app know, or care how to consume typescript.

I've left a more detailed discussion issue over at ember-cli-typescript typed-ember/ember-cli-typescript#1443

[scalvert]

Let's wait for a discussion on this. I'm fine to make changes in this space, but I want to do what the standard is rather than a one-off.

[stefanpenner]

@scalvert and me chatted, he is ok with a few libraries (such as this one) being part of some early experimentation in the space as we build up some evidence + examples to properly improve both ember-cli-typescript and embroiders v2 package format with regards to ts support.

This is also important, as without this several consumers are broken, which implies a breaking change has already landed.

I do agree a good standard here will be important, and we can use this short-term fix as information to help solve that bigger picture. Once solved we can loop back and upgrade this project

[chriskrycho]

@stefanpenner can you elaborate on this?

This is also important, as without this several consumers are broken, which implies a breaking change has already landed.

It's not clear to me how things were broken, and without that it's difficult to understand why this is the solution. Per discussion on typed-ember/ember-cli-typescript#1443, we want to move to align the Ember ecosystem with the rest of the TS ecosystem as part of the move to Embroider, but the way this worked historically has actually never required consuming apps or addons to know or care that there's TS involved: it happens transparently for them.

If that doesn't hold here, that means that (a) something is wrong in the publishing package; or (b) that there's a bug somewhere in the ember-cli-typescript + ember-cli-babel chain.

While (b) is definitely possible, a very large (and ever-growing!) number of packages in the ecosystem work just fine with the current flow, so it would be helpful to know exactly what you saw here.

(Also, as a point of clarification: there's basically zero extra overhead for consumers in the way we currently publish addons, because it's just another Babel transform. The only time that type checking gets involved is if the consuming addon itself chooses to add ember-cli-typescript—and even then, it has the choice of whether to type check its dependencies via the compilerOptions.skipLibCheck setting in tsconfig.json.)

[stefanpenner]

@chriskrycho its been to long, but a a semver drift of @ember/test-helpers broke a consuming app or add-on due to this issue in this repo.

Unfortunately I've been working my way through too many add-ons the last few months, I wish I could have noted it in this issue.