Add note for workaround for --typescript issues

[NullVoxPopuli]

tl;dr:

• this is only needed if:
  • Use built in types from ember-source instead of the types-packages #118 is merged
  • and ember new my-app --typescript is still using types from DT
  • and someone wants to use yarn with a v2 addon monorepo

---

People are using the v2 addon blueprint, and when trying to use --typescript, there are undocumented / hard to find issues with how --typescript works in ember-cli right now.

This README updates documents some of those, and adds some manual instructions so folks get be unblocked.
(It's important to unblock folks while we work on a proper solution, as folks want to do what they want to do, and we/I need to enable them 🎉 )

There are a few changes in ember-cli-typescript that could probably help this situation, but also, I don't blame anyone for not staying on top of it -- better changes for TypeScript are just around the corner, and effort is better (and has been!) spent there.

https://github.com/typed-ember/ember-cli-typescript/commits/master

• Last release was October
• Needed since last release:
  • Remove @types/ember__test-helpers Remove deprecated @types/ember__test-helpers from blueprint typed-ember/ember-cli-typescript#1545
  • Remove @types/ember-resolver Remove @types/ember__resolver typed-ember/ember-cli-typescript#1557
  • Remove @types/ember__string Remove @types/ember__string typed-ember/ember-cli-typescript#1558
  • Remove @types/ember-qunit Remove @types/ember-qunit because ember-qunit provides its own ty… typed-ember/ember-cli-typescript#1559

Ultimately, I think the best thing for folks to do if they are starting new projects is to use the preview types. They are so much a better experience, that I can't believe we've used the types from DT for so long. The typed-ember team has done an amazing job on making TS a native experience.
See this other PR for native types: #118

[simonihmig]

Why do you propose this as a separate step? What does it help with?

[NullVoxPopuli]

How else do you make a v2 addon monorepo with typescript?

[simonihmig]

Just npx ember-cli@latest addon my-addon -b @embroider/addon-blueprint --typescript?

[NullVoxPopuli]

it's broken-by-default (with some asterisks)

Here is that command's output in StackBlitz: https://stackblitz.com/edit/node-iuvwaw
Repro:

cd my-addon
yarn

Issues I noticed:

• using --typescript ended up using --yarn, but without teh --yarn flag so the v2 blueprint was generated assuming npm 🙈
• $ npm run build --workspace my-addon seems to infinite loop under yarn 😅
  • had to fix this / remove prepare to get on with this demo 😅

I noticed that lint:types works with using the non-preview types under yarn.
So here is a small change to use the preview types as in #118,
https://stackblitz.com/edit/node-okq4r6?file=my-addon%2Fpackage.json,my-addon%2Fmy-addon%2Funpublished-development-types%2Findex.d.ts,my-addon%2Fmy-addon%2Fpackage.json

cd my-addon
yarn
yarn lint
# error! mismatched types

The reason this is a yarn problem is that the v2-addon's usage of ember-source's built-in types is a development concern, which the consuming app's types shouldn't care about.

The way I'm thinking of trying to solve it is to get us off of DT's types.
Part 1: #118
Part 2: make the app blueprint use native types as well? (or merge all the ec-typescript PRs -- but I'm not confident that the DT types can be made compatible with a yarn monorepo)

Here is an example of what the state of things are with the built-in types, and also with the ec-ts changes:
https://stackblitz.com/edit/node-n5yqmy?file=my-addon%2Fpackage.json,my-addon%2Fmy-addon%2Funpublished-development-types%2Findex.d.ts,my-addon%2Ftest-app%2Fpackage.json

Same issue.

However, if the generated app were to use the built in types as well: https://stackblitz.com/edit/node-3txw9q?file=my-addon%2Fpackage.json,my-addon%2Ftest-app%2Ftypes%2Findex.d.ts,my-addon%2Ftest-app%2Fpackage.json
then everything works.

[NullVoxPopuli]

one thing that I think could hold up the default app blueprint from using native types is that I don't know of ember-data is ready for its built in types to be used.

[NullVoxPopuli]

If we drop support for --yarn then.. all of this is a non issue 😅
(not saying we actually do that, but like all things, dropping yarn makes everything easier. lol)

[simonihmig]

Sorry, but I am not really following...

I'd like to keep using the native types out of this discussion, as this seems a separate topic and the current blueprint should work with what we have now...

using --typescript ended up using --yarn

Ok, haven't tested this, but if this is the case, then let's fix this.

npm run build --workspace my-addon seems to infinite loop under yarn

But why are you using this command with yarn?

I did npx ember-cli@latest addon my-addon -b @embroider/addon-blueprint --typescript --yarn just now. And there is an error popping up, due to @types/ember__test-helpers being still used by the test-app. I already removed this here, but this hasn't been released yet unfortunately.

When removing @types/ember__test-helpers, then all of this just works fine for me:

• yarn lint
• yarn test
• yarn build
• yarn start

If we drop support for --yarn then.. all of this is a non issue 😅

Again, why?

Why do you propose this as a separate step? What does it help with?

You haven't really answered that question yet. What makes running those two blueprints separately better, when our blueprint does literally the same (when not using --addon-only)

[NullVoxPopuli]

I'd like to keep using the native types out of this discussion

They are entirely related though, to ignore native types means there is no issue with yarn.

Again, why?

yarn is resolving types incorrectly -- afaict, is the only package manager that can't handle native types in the addon and DT types in the test app :(

[simonihmig]

Then I don't understand the scope of this PR. It is adding a note for TS users, it is not introducing preview types. This is what #118 is doing, and we can only land that one if it works correctly, including with yarn. But without preview types, --typescript --yarn is (mostly) working. So what are we doing here?

You haven't really answered that question yet. What makes running those two blueprints separately better, when our blueprint does literally the same (when not using --addon-only)

?

[NullVoxPopuli]

yeah, apologies for the confusion -- it's entirely possible I've over-corrected for being told that -- my PRs are too big and that's why folks never review any of my stuff in OSS (which is fair criticism, but splitting things up also makes it hard for folks to see the whole story of a change) -- and now this PR doesn't make sense in isolation.

It is Draft, and I've (just now) added 3 important caveats to the top.
Also!, I'm totally happy with this PR not ever merging, and only being a documentation of sorts for folks that run in to the situation that we've run in to, with the ecosystem between between native types and DT types.

[NullVoxPopuli]

It's looking like yarn@v1's nohoist on ember-source is resolving the problem. #118

Will close.