Use built in types from ember-source instead of the types-packages

[NullVoxPopuli]

This PR is blocked until:

• ember new my-app --typescript uses the built in types (see discussion Add note for workaround for --typescript issues #123)
  • due to yarn@v1 not resolving types directly? this are getting weirder as I investigate this. the TS test that's failing uses both yarn and pnpm.
  • npm and pnpm can handle the app using types from DT and the addon using native types

---

This reduces a lot of the dependency management that folks need to do.

Best of all, this change shouldn't affect consumers of existing v2 addons as there are developement-only types.
(with the caveat that some of the types from DT may not be compatible with the built-in ember-source types)

[NullVoxPopuli]

This is required by glint

[NullVoxPopuli]

highly likely a v2 addon will want a peer on ember-source

[simonihmig]

Seems good to me, especially since the v1 blueprint also has this, but I remember this comment by @ef4 🤔

the main reason people are forced to add it is if they want to say dependencySatisfies('ember-source', ...).

but this is the case quite often, often implicitly by others doing this, e.g. see ember-polyfills/ember-cached-decorator-polyfill#212

So I'm 👍, but just wanted to make sure...

[NullVoxPopuli]

hmmm that's a good point. I'll hopefully remember to bring this up in tomorrows meeting.

[NullVoxPopuli]

The typescript test is using yarn@v1 which manages dependencies incorrectly, and gives us this error during build:

[!] (plugin Typescript) TS2688: Cannot find type definition file for 'ember__test-helpers'.
  The file is in the program because:
    Entry point for implicit type library 'ember__test-helpers'

This is with a project generated via:

❯ npx ember-cli addon ts-project -b ../OpenSource/addon-blueprint/ --skip-git --yarn --typescript

changing nothing else about ts-project

• delete all node_modules recursively
• delete yarn.lock
• add pnpm-workspace.yaml that has these contents:

  packages:
  

• test-app
• ts-project

- run `pnpm i`
- cd `ts-project`
- run `pnpm build` (same as previous `yarn build` aka `rollup -c`) 

🎉 success

This will be a problem unless we set `nohoist` in `yarn` projects to include `ember-source` -- but I believe that'll still resolve incorrectly when it comes time for the addon developer to use ember-try.

I kinda think we should explicitly _not_ support `yarn@v1` for as long as the v2 addon blueprint is a monorepo.

(long term, I have a plan to make the v2 addon blueprint a uni-repo repo like the v1 addon blueprint is, but that's a ways off as it requires the vite work from embroider, and a special vite plugin from addon-dev that doesn't exist yet for an in-memory test-app -- ( and I think we should still support the monorepo workflow, as it's the only real way to test if a package is actually being built correctly, but I don't think we can support yarn@v1 with the monorepo layout ))

[NullVoxPopuli]

It's likely this problem will go away when the --typescript app blueprint uses the built in types.

@chriskrycho -- I remember reading you ran in to some issues promoting the preview types to stable -- do you have those listed anywhere, so I can make note of them?

[simonihmig]

Seems good to me, especially since the v1 blueprint also has this, but I remember this comment by @ef4 🤔

the main reason people are forced to add it is if they want to say dependencySatisfies('ember-source', ...).

but this is the case quite often, often implicitly by others doing this, e.g. see ember-polyfills/ember-cached-decorator-polyfill#212

So I'm 👍, but just wanted to make sure...

[NullVoxPopuli]

Moving to draft, as I have some things to explore, and later extract from this PR.

[NullVoxPopuli]

this will go away with this PR: #136