Project References

Glint works out of the box with TypeScript’s Project References feature: Instead of running just glint, you run glint --build, and Glint will correctly do incremental builds for composite projects.
This is not a guide to project references and composite projects. Instead, see the TypeScript docs.
As with project references in general, there are a few extra pieces of configuration to add, though.
Shared project-wide configuration
First, as with project references in general, you should define your glint config in a shared compiler options tsconfig.json at the root. For example, you might have something like this as a tsconfig.shared.json:
{
  "compilerOptions": {
    // ...
  },
  "glint": {
    "environment": "ember-template-imports"
  }
}
Then each project within can use the extends key to reuse both TypeScript and Glint configuration. For example, if your project has sub-projects all located in packages/<project>, a sub-project might have a tsconfig.json file like this:
{
  "extends": "../../tsconfig.shared.json",
  "compilerOptions": {
    "composite": true
  }
}
Per-project configuration
To work with Glint, each sub-project needs to include the Glint environment imports it uses. (See Ember: Installation and GlimmerX: Installation for details.) For example, a project using ember-template-imports should have this import visible somewhere:
import '@glint/environment-ember-template-imports';
The easiest way to do this is to add it to a shared file all projects can reference using the include key in each sub-project's tsconfig.json. If you do not already have something filling this role, you should introduce a local-types directory (named however you like) in the root of your project, with an index.d.ts in it.
If you are using ember-cli-typescript, you can do this in the types/index.d.ts file created automatically for you by the addon. Just make sure you add that directory to the include field in all your sub-project tsconfig.json files.
The resulting project structure might look something like this, given sub-projects in packages which have their TypeScript source files in a src directory:
.
├── package.json
├── packages
│   ├── a
│   │   ├── local-types
│   │   │   └── index.d.ts
│   │   ├── package.json
│   │   ├── src
│   │   └── tsconfig.json
│   └── b
│       ├── package.json
│       ├── src
│       └── tsconfig.json
├── tsconfig.json
├── tsconfig.shared.json
└── local-types
    └── index.d.ts
With this structure, the sub-project configurations, like packages/a/tsconfig.json, can be very minimal. The only things they need to do are:
extend the root options config
include the types directory as well as their own files
{
  "extends": "../../tsconfig.shared.json",
  "compilerOptions": {
    "composite": true
  },
  "include": ["../../local-types", "./src"]
}
Customizing sub-project configuration
If needed, you can customize each sub-project by overriding its glint settings, just as you can with compilerOptions. For example, if you have one sub-project which is using the ember-loose environment instead of ember-template-imports, you would need to make two changes for that package:
include the corresponding import in a file in the project (or in another shared location)
update the glint config in that project's tsconfig.json
If this were in sub-project a from the example above, the resulting layout might look like this:
├── packages
│   ├── a
│   │   ├── local-types
│   │   │   └── index.d.ts
│   │   ├── package.json
│   │   ├── src
│   │   └── tsconfig.json
The updated packages/a/tsconfig.json file might look like this:
{
  "extends": "../../tsconfig.shared.json",
  "compilerOptions": {
    "composite": true
  },
  "include": ["./local-types", "./src"],
  "glint": {
    "environment": "ember-loose"
  }
}
Note that here it uses local-types from a, not from the root. You can also have both present:
{
  "include": ["../../local-types/**/*.ts", "./local-types/**/*.ts", "./src/**/*.ts"]
}
The key is to make sure each project has all required imports available, and not to have imports present which a given sub-project does not require.
Last modified 6mo ago