Can this run as part of ember build?

[tansongyang]

Hello, and thanks for the great work on this!

We have enabled Glint by default in our project, and it's super helpful. However, the one inconvenient thing about it right now is that we have to run Glint manually to type check. It doesn't "just happen" as part of ember build, ember serve, etc., the way TS does.

Is this already documented somewhere, or is it on the roadmap? Thanks!

[chriskrycho]

Hey @tansongyang – good question! We haven't expressly documented this anywhere, I think, so this is a good spot for it (and also I've converted this to a “Discussion”): the answer is no, and there is actually a forthcoming RFC to move away from injecting TS errors into ember build from ember-cli-typescript. We implemented that functionality many years ago because was the strong expectation from the Ember community, but it was somewhat out of step even then with the norms of the broader TS community. Our current recommendation (if you ask any of us directly, anyway; we haven’t otherwise documented this!) is to run tsc or glint in a second process, rather than integrated into the build—in much the same way you might with eslint etc.

There are a few additional reasons (besides “this is how the rest of the ecosystem tends to do it”) that we are moving that way:

1. As Ember itself moves to using ecosystem-standard tools (webpack, Vite, etc.), there will not be one way to inject into a build, but potentially many. We would prefer that if people want a webpack glint-loader which can inject failures into the build (the way ts-loader can), they build that (and we will of course support that as we’re able).

2. The integration point has always been fragile, and it’s a non-trivial maintenance burden!

3. Making the ember build integration work for TS composite projects—even just for tsc itself—was more or less a non-starter, so we would need to support both direct invocation (glint --build --watch) and the integration with the build. I spent some time poking at that last year, and there is just a fundamental mismatch between the way TS handles type checking in composite projects and the way tools like Ember CLI (or webpack or others) work. The only one I’m aware of which does support composite projects at all is the ts-loader for webpack, and it does a lot of work to that end.

Net, we will not be supporting direct integration with ember build, but it was a reasonable thing to suggest!

---

Bonus: We know this is mildly less convenient than just having a single command to run. For the developers at LinkedIn, we are using tmux conjunction with the start script in package.json to make it so that folks can just type yarn start and get both ember serve and glint --build --watch running. For anyone who’s curious, this is how that script is set up, including some niceties for folks using iTerm2:

#!/bin/sh

NAME=ember-app

tmux new-session -s $NAME -d

tmux set-option -g mouse on

tmux split-window -h
# running yarn ts:watch here breaks cause of yarn recursion or something
tmux send-keys -t $NAME "yarn glint:watch" C-m
tmux last-pane
tmux send-keys -t $NAME "ember serve" C-m

if [ "$TERM_PROGRAM" = "iTerm.app" ]
then
  tmux -CC attach -t $NAME
else
  tmux attach -t $NAME 
fi

One big upside to this: if there are other things which should be part of your development experience—e.g. generating type definitions for the API or for CSS—those can similarly be their own scripts, with no need for them to be aware of some host build process.

[tansongyang]

Thanks as always for the helpful explanations! 👏