blueprint still references ember global, which doesn't exist in v4

[NullVoxPopuli]

This is in the same app as this issue:

Please paste the output of ember -v here

❯ ember -v
ember-cli: 4.3.0
node: 16.13.1
os: linux x64

Please paste the output of tsc -v here

❯ pnpm exec tsc -v
Version 4.6.4

Please paste the version of ember-cli-typescript and ember-cli-typescript-blueprints here

❯ cat package.json | grep typescript
    "ember-cli-typescript": "^5.1.0",
    "ember-cli-typescript-blueprints": "^3.0.0",
    "typescript": "^4.6.4",

Please paste your tsconfig.json and tslint.json or eslint.json (if applicable) below

My tsconfig.json

{
  "compilerOptions": {
    "target": "ES2021",
    "module": "ES2020",
    "moduleResolution": "node",

    // Trying to check Ember apps and addons with `allowJs: true` is a recipe
    // for many unresolveable type errors, because with *considerable* extra
    // configuration it ends up including many files which are *not* valid and
    // cannot be: they *appear* to be resolve-able to TS, but are in fact not in
    // valid Node-resolveable locations and may not have TS-ready types. This
    // will likely improve over time
    "allowJs": false,

    // --- TS for SemVer Types compatibility
    // Strictness settings -- you should *not* change these: Ember code is not
    // guaranteed to type check with these set to looser values.
    "strict": true,
    "noUncheckedIndexedAccess": true,

    // Interop: these are viral and will require anyone downstream of your
    // package to *also* set them to true. If you *must* enable them to consume
    // an upstream package, you should document that for downstream consumers to
    // be aware of.
    //
    // These *are* safe for apps to enable, since they do not *have* downstream
    // consumers; but leaving them off is still preferred when possible, since
    // it makes it easier to switch between apps and addons and have the same
    // rules for what can be imported and how.
    "allowSyntheticDefaultImports": false,
    "esModuleInterop": false,

    // --- Lint-style rules

    // TypeScript also supplies some lint-style checks; nearly all of them are
    // better handled by ESLint with the `@typescript-eslint`. This one is more
    // like a safety check, though, so we leave it on.
    "noPropertyAccessFromIndexSignature": true,

    // --- Compilation/integration settings
    // Setting `noEmitOnError` here allows ember-cli-typescript to catch errors
    // and inject them into Ember CLI's build error reporting, which provides
    // nice feedback for when
    "noEmitOnError": true,

    // We use Babel for emitting runtime code, because it's very important that
    // we always and only use the same transpiler for non-stable features, in
    // particular decorators. If you were to change this to `true`, it could
    // lead to accidentally generating code with `tsc` instead of Babel, and
    // could thereby result in broken code at runtime.
    "noEmit": true,

    // Ember makes heavy use of decorators; TS does not support them at all
    // without this flag.
    "experimentalDecorators": true,

    // Support generation of source maps. Note: you must *also* enable source
    // maps in your `ember-cli-babel` config and/or `babel.config.js`.
    "declaration": true,
    "declarationMap": true,
    "inlineSourceMap": true,
    "inlineSources": true,

    // The combination of `baseUrl` with `paths` allows Ember's classic package
    // layout, which is not resolveable with the Node resolution algorithm, to
    // work with TypeScript.
    "baseUrl": ".",
    "paths": {
      "repro-glint-gts-error-parse-node/tests/*": [
        "tests/*"
      ],
      "repro-glint-gts-error-parse-node/*": [
        "app/*"
      ],
      "*": [
        "types/*"
      ]
    }
  },
  "include": [
    "app/**/*",
    "tests/**/*",
    "types/**/*"
  ]
}

What are instructions we can follow to reproduce the issue?

ember new my-app
cd my-app
ember install ember-cli-typescript
ember s 
# => errors

Reproduction Case

I have this repo, which I was trying to repo an unrelated error:

• https://github.com/NullVoxPopuli/repro-glint-gts-error-parse-node

See commits: https://github.com/NullVoxPopuli/repro-glint-gts-error-parse-node/commits/main

the error is present from the 3rd commit NullVoxPopuli/repro-glint-gts-error-parse-node@10fe083

all the way until the work around is implemented: NullVoxPopuli/repro-glint-gts-error-parse-node@5843cbc
(I just deleted the types/<app-name> folder)

What happened instead?

❯ pnpm start

> repro-glint-gts-error-parse-node@0.0.0 start /home/nullvoxpopuli/Development/NullVoxPopuli/repro-glint-gts-error-parse-node
> ember serve

Building into /tmp/embroider/d85e90

types/repro-glint-gts-error-parse-node/index.d.ts:1:19 - error TS2307: Cannot find module 'ember' or its corresponding type declarations.

1 import Ember from 'ember';
                    ~~~~~~~

[chriskrycho]

The error you're showing has nothing to do with the global. (If you see an import statement, by definition you're not dealing with a global. 😉) Based on the error message, it looks like the issue may be that we're not installing @types/ember, only the modules types (@types/ember__object etc.). If we are still importing from it, then TS may be grumpy about that. The fix would be to include @types/ember directly. Can you do that and confirm that fixes this?

If so, please open a PR to fix it by adding it here:

ember-cli-typescript/ts/blueprints/ember-cli-typescript/index.js

Lines 149 to 172 in 52009e2

	let packages = [
	'typescript',
	'ember-cli-typescript-blueprints',
	'@types/ember-resolver',
	'@types/ember__test-helpers',
	'@types/ember__object',
	'@types/ember__service',
	'@types/ember__controller',
	'@types/ember__string',
	'@types/ember__template',
	'@types/ember__polyfills',
	'@types/ember__utils',
	'@types/ember__runloop',
	'@types/ember__debug',
	'@types/ember__engine',
	'@types/ember__application',
	'@types/ember__test',
	'@types/ember__array',
	'@types/ember__error',
	'@types/ember__component',
	'@types/ember__routing',
	'@types/rsvp',
	'@types/htmlbars-inline-precompile',
	];