You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, Glint v1 tries to typecheck all templates, not just GTS files. There doesn't seem to be a way to scope typechecking just to GTS & TS files while still enabling common tsconfig options like allowJs. For large legacy applications, this presents a hurdle for Glint adoption, because the only path forward seems to be to add glint-nocheck directives to the top of every HBS file that fails Glint's typechecking. There is a codemod for this, yes, but even so the lift can be large enough as to be unfeasible for some teams. For example, when I ran a test in one of our codebases a few months ago, it required adding Glint directives to nearly 600 files. Even after doing that, teams would also need to educate developers on how to handle Glint directives should new errors pop up that they're not prepared to address at that time.
This is a huge amount of overhead for what should be a fairly simple task: Adding functional typechecking for GTS files. We need a way to make Glint adoption more straightforward by configuring it to skip typechecking for HBS files as a intermediate onboarding step until teams are ready to tackle their legacy components. Otherwise, teams are stuck choosing between taking on the large overhead of onboarding Glint as it stands today, or not adopting Glint at all, which becomes a blocker for using GTS components since typechecking will be broken with the regular tsc commands. Speaking from experience, the end result of Glint's current state is that developers will choose to just not bother with GTS components at all, because they value functional typechecking more than they value single-file components. I'd like to change that story, but Glint needs a better adoption path than it has today.
The text was updated successfully, but these errors were encountered:
At minimum, I think it would be good planning to make sure that when support for two-file components gets added to Glint v2, that it's configurable rather than forced on by default with no way to disable. :)
Right now, Glint v1 tries to typecheck all templates, not just GTS files. There doesn't seem to be a way to scope typechecking just to GTS & TS files while still enabling common tsconfig options like
allowJs
. For large legacy applications, this presents a hurdle for Glint adoption, because the only path forward seems to be to addglint-nocheck
directives to the top of every HBS file that fails Glint's typechecking. There is a codemod for this, yes, but even so the lift can be large enough as to be unfeasible for some teams. For example, when I ran a test in one of our codebases a few months ago, it required adding Glint directives to nearly 600 files. Even after doing that, teams would also need to educate developers on how to handle Glint directives should new errors pop up that they're not prepared to address at that time.This is a huge amount of overhead for what should be a fairly simple task: Adding functional typechecking for GTS files. We need a way to make Glint adoption more straightforward by configuring it to skip typechecking for HBS files as a intermediate onboarding step until teams are ready to tackle their legacy components. Otherwise, teams are stuck choosing between taking on the large overhead of onboarding Glint as it stands today, or not adopting Glint at all, which becomes a blocker for using GTS components since typechecking will be broken with the regular
tsc
commands. Speaking from experience, the end result of Glint's current state is that developers will choose to just not bother with GTS components at all, because they value functional typechecking more than they value single-file components. I'd like to change that story, but Glint needs a better adoption path than it has today.The text was updated successfully, but these errors were encountered: