publishing TS seems surprising

[stefanpenner]

Hey guys, I was surprised to see ember-cli-typescript encourages folks to publish Typescript.

My expectation was:

• published .d.ts and .js files, but not .ts files

What i see:

• published '.d.ts' and '.ts'

Why is I believe this a problem:

• I believe, but do correct me if I am wrong, but publishing the TS itself isn't the TS recommendation
• publishing TS, and having the consuming app process creates both a build time and dependency liability penalty on the consuming app.
• for example, @ember/string today cannot simply install @ember/test-helpers without crashing due to unexpected TS syntax, without updating/fixing its own dependencies.
• for example, functioning apps now have excessive dependencies which could be "precompiled" away.

My current thoughts on solving (early, but evolving, would love input):

Publish only .js + .d.ts, and have all TS related build dependencies as dev dependencies.
Local add-on development, including linking, would be handled as:

• tsc -p tsconfig.json --noEmit is used for linting by editor + yarn lint
• the ember build pipeline would simply strip ts via @babel/preset-typescript (maybe under the hood via https://github.com/stefanpenner/broccoli-babel-preset-typescript)
• prepublish would produce: (1) babel stripped .js files (2) typescript produced d.ts files
• .npmignore and .gitignore would be use to ensure only the right files are published and committed.

[chriskrycho]

Hey @stefanpenner, thanks for the issue. Roughly what you describe here is what we expect to move to as part of the ecosystem move to Embroider. We chose this approach several years ago for reasons I don't remember—I believe as part of moving to the Babel-based compilation pipeline, and in the interest of making the behavior identical for apps and addons, regardless of whether an addon is published or symlinked.

However, we've moved the ecosystem quite a bit since then, including having "out of the box" support for compiling .ts files with Babel as part of the regular build pipeline as long as ember-cli-typescript is installed, so much of that is no longer necessary. Good blueprints should allow us to do exactly as you suggested for published artifacts with .js and .d.ts.

That all being said, it's been a while and I may have forgotten a constraint here, so input and/or correction from @jamescdavis and @dfreeman very welcome and appreciated!

[chriskrycho]

Follow-up here as I'm refreshing my memory in chatting with Dan about this:

ember-cli-typescript v1 actually did exactly this, not least because it is how the rest of the TS ecosystem works… but that was a very bumpy experience for Ember devs. At the point we moved to this, the Ember community expected ember-cli-typescript to work the same way every other part of the build did—ember-cli-babel, addons which supplied AST transforms for Handlebars, etc.

That is, they expected their addons to "just work" regardless of whether they were symlinked, in "development" mode, an in-repo addon, etc., without a publish step. And they were right to expect that, given that fundamentally, the pre-Embroider view of the world for addons is that addons are published in their authoring format, and the build is responsible for assembling it. So… we made ember-cli-typescript do that!

In the Embroider world, there is an expectation of a pre-publish step, so that what ends up distributed is spec-compliant JS. (I know you know this; I'm adding it here in part for anyone else in the ecosystem reading along.) Given that, it will make a great deal of sense to ultimately switch back to the way the rest of the TS ecosystem works. In the meantime, however, we're unaware of any actual bugs arising from the current way the system works.

---

To dig in on a few points in particular:

• publishing TS, and having the consuming app process creates both a build time and dependency liability penalty on the consuming app.

It does, but no more than any Babel plugin does, and again this is in line with the rest of the ecosystem. There is no type-checking unless the consuming app (or addon) itself opts into type-checking via ember-cli-typescript (or its own custom/manual process).

• for example, @ember/string today cannot simply install @ember/test-helpers without crashing due to unexpected TS syntax, without updating/fixing its own dependencies.

As noted on emberjs/ember-test-waiters#293, it's not clear exactly what bug/issue you hit, so a detailed writeup there or here would be helpful. But in general, the statement made here is not true. There may be specific things about the builds for @ember/string or @ember/test-helpers which are causing issues, or there may be things which are otherwise/independently broken, or there may be a bug we're currently unaware of in the ember-cli-typescript + ember-cli-babel pipeline, but we know that it's not a general problem: the ecosystem has been working this way for years without any major issues.

• for example, functioning apps now have excessive dependencies which could be "precompiled" away.

See discussion above. 😉

• tsc -p tsconfig.json --noEmit is used for linting by editor + yarn lint

This is basically how things already work. We integrate it into the build pipeline both to give good feedback and so that people do not have to manually spin up multiple processes in parallel. In the future, we may be able to use e.g. ts-loader in webpack to do the same, but having it integrated into the build so that users see errors is a strong ecosystem norm. (It's also one that can be configured using the noEmitOnError flag.)

• the ember build pipeline would simply strip ts via @babel/preset-typescript…

This is already how it works.

• prepublish would produce: (1) babel stripped .js files (2) typescript produced d.ts files
• .npmignore and .gitignore would be use to ensure only the right files are published and committed.

See discussion above. 😉 (Also, prepublish already does (2).)

[stefanpenner]

ember-cli-typescript v1 actually did exactly this
That is, they expected their addons to "just work" regardless of whether they were symlinked, in "development" mode, an in-repo addon, etc., without a publish step. And they were right to expect that, given that fundamentally, the pre-Embroider view of the world for addons is that addons are published in their authoring format, and the build is responsible for assembling it. So… we made ember-cli-typescript do that!

I'm not sure why this was an issue in the past, but it is handled by the above proposal (and my prototypes) without issue. TL;DR i believe the current ember-cli-typescript architecture nearly enables this.

We integrate it into the build pipeline both to give good feedback

Having worked with this, and spoken to others that have worked with this it isn't clear this is a good experience for a majority of users, or all developer tasks.

• For some, this is the perfect set of trade-offs.
• For others, although they like the feedback, but are unaware of the additional costs re: build speed / memory usage penalties.
• Others are frustrated by the workflow interruptions.

Given that, both capabilities seem appropriate and providing the current developer the option to choose the mode which bests suites their task, and development preferences seems appropriate.

What the default should be is unclear.

[dfreeman]

I'm not sure why this was an issue in the past, but it is handled by the above proposal (and my prototypes) without issue. TL;DR i believe the current ember-cli-typescript architecture nearly enables this.

The key difference between your proposal above and what ember-cli-typescript does today is the bit where TS-specific syntax is stripped out before publish. To rephrase what I think @chriskrycho was saying above, publishing non-standard syntax and letting ember-cli-babel take care of it during the host build is the de facto standard for v1 addons across the ecosystem. If an addon wants to use e.g. the pipeline operator, as long as the appropriate Babel plugin is included in their config, that syntax works without the host application needing to know or care about it, just as things like optional chaining and decorators did for many addons before they became a default part of the toolchain. While TS syntax isn't an ES standard proposal, fundamentally the mechanism used to handle that syntax is the same.

To your point, all of that changes with the v2 addon spec, since it gives a defined target for publishing rather than today's "ship what you want along with the tools to deal with it" approach. I'm wary of trying to move TS addons to that model ahead of v2 becoming the standard, though, as it runs counter to developers' expectations today and creates a short-term project setup that authors will need to migrate to before then changing over once again after a standard publish process is established for all addons.

Having worked with this, and spoken to others that have worked with this it isn't clear this is a good experience for a majority of users, or all developer tasks.

Both options are already available to developers today. Folks who aren't interested in integrated typechecking can forgo the use of ember-cli-typescript entirely and set enableTypeScriptTransform: true in their ember-cli-babel configuration.