The --project argument was being treated as a path to some location inside the project, rather than as either a path to a tsconfig file or a path to a folder containing a tsconfig file, which is how tsc implements it. This meant that there was no way to run glint and use a config file named anything other than tsconfig.json.
This is a breaking change because if anybody was passing a project path that pointed deeply into the project, that will no longer work. Similarly, the analyzeProject() unstable API's behavior has changed, and loadConfig export has been replaced with loadClosestConfig and loadConfigFromProject exports.
We could switch back to only having a single loadConfig() method that checks to see if its path points to a config file, and if not falls back on the pre-existing logic, but I thought that would be kinda confusing, and it would be better for the behavior to match that of tsc even though that requires a technically-breaking change.
The
--project
argument was being treated as a path to some location inside the project, rather than as either a path to a tsconfig file or a path to a folder containing a tsconfig file, which is howtsc
implements it. This meant that there was no way to runglint
and use a config file named anything other thantsconfig.json
.This is a breaking change because if anybody was passing a project path that pointed deeply into the project, that will no longer work. Similarly, the
analyzeProject()
unstable API's behavior has changed, andloadConfig
export has been replaced withloadClosestConfig
andloadConfigFromProject
exports.We could switch back to only having a single
loadConfig()
method that checks to see if its path points to a config file, and if not falls back on the pre-existing logic, but I thought that would be kinda confusing, and it would be better for the behavior to match that oftsc
even though that requires a technically-breaking change.