Fix project argument to match tsc #709
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
dfreeman
reviewed
Mar 14, 2024
| @@ -40,6 +41,6 @@ export function analyzeProject(projectDirectory: string = process.cwd()): Projec | |||
| }; | |||
| } | |||
|
|
|||
| export { loadConfig }; | |||
There was a problem hiding this comment.
I know we've been careful not to make any commitments on the stability of any of these exports, but it looks like there are at least a couple real-world instances of folks relying on this.
Can we keep loadConfig around as a deprecated function that logs a warning that consumers should update to either loadClosestConfig or loadConfigFromProject and then calls through to loadClosestConfig to preserve existing behavior?
There was a problem hiding this comment.
Yeah, makes sense! console.warn or do we have another method for issuing deprecation warnings?
packages/core/src/config/loader.ts
Outdated
| */ | ||
| public configForProjectPath(configPath: string): GlintConfig | null { | ||
| let tsConfigPath = path.join(configPath, 'tsconfig.json'); | ||
| let jsConfigPath = path.join(configPath, 'tsconfig.json'); |
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.
bendemboski
force-pushed
the
fix-project-arg
branch
from
669af32
to
6740357
Compare
|
@dfreeman I've addressed your feedback in a separate commit that I'll squash into the first commit if it all looks good |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The
--projectargument 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 howtscimplements it. This meant that there was no way to runglintand 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, andloadConfigexport has been replaced withloadClosestConfigandloadConfigFromProjectexports.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 oftsceven though that requires a technically-breaking change.