Hey, thanks for the package. Could you please publish it on npm? Cloning and building it manually seems weird.

Original: iisaduan/ts-fix#3

interface I {}

declare const obj: I;

obj.foo;
//  ^^^ Property 'aa' does not exist on type 'I'.ts(2339)

This error returns two fixes:

For each, the fixName is fixMissingMember. They represent two different ways of fixing the same thing. I believe the current code will try to apply them both. Unfortunately, there’s not actually a way to differentiate them besides their description property, which is dynamic.

A minimal fix, probably good enough to start with, would be to only apply the first fix returned for a given error, since we try to sort the most likely fixes first. If we need more granularity, we’d need an API change from TypeScript itself.

The path created to the git repo folder for checking its status uses an explicit backslash instead of path.join() which causes it to throw an error on MacOS:

/path/to/repo/node_modules/ts-fix/dist/index.js:90
            throw new Error(err.message);
            ^

Error: Command failed: git --git-dir="/path/to/repo\.git" --work-tree="/path/to/repo" status --porcelain
fatal: not a git repository: '/path/to/repo\.git'

    at /path/to/repo/node_modules/ts-fix/dist/index.js:90:19
    at ChildProcess.exithandler (node:child_process:404:5)
    at ChildProcess.emit (node:events:390:28)
    at maybeClose (node:internal/child_process:1064:16)
    at Socket.<anonymous> (node:internal/child_process:450:11)
    at Socket.emit (node:events:390:28)
    at Pipe.<anonymous> (node:net:687:12)

The path is generated here.

This happens even with the --ignoreGitStatus flag.

• gitStatus needs to be tested, unable to use -w when testing integration > cases because the functionality hasn't been implemented in TestHost. In Andrew's words "git status functionality should be done through the Host, and a mock Host can be injected into the test runs that returns fake results for git operations".
• gitStatus needs support for when the repository and the project folder are on a different absolute path

Original: iisaduan/ts-fix#19

@andrewbranch commented
This will never be true since arrays are compared by reference equality. I don’t think the condition is needed, though?
https://github.com/iisaduan/ts-fix/blob/90a7e5ce6e25ac064bdc38a0833d9a8731cb11f0/src/index.ts#L70

This line is now

• Add Back option in the showMultiple menu in --interactiveMode
• Maybe let the user decide when to write to files so they don't have to sit through all of it, if they can't
• Keep a counter of how many fixes are left after each accept, skip, acceptall, rejectall, etc.
• Let the user decide how many passes to allow
• Truncate notappliedFixes, allChangesFiles, etc. in printSummary
• Implement exclude flags - what if a user wants to exclude some code fixes or some error codes?

Original issue: iisaduan/ts-fix#15

@andrewbranch commented July 28, 2021
I think we should do away with the default of applying all available fixes. It’s bound to produce a ton of undesired changes.

@iisaduan commented Aug 13, 2021
Currently, behavior is fixes are only applied if at least one of errorCode or fixName is supplied. Otherwise process exits with warning. 26bb5c6

There could be other ways to handle the case where no fixes or errors are given, such as printing what errors and fixes are present

Currently, the tool accepts all fixes that don't collide, and if there are colliding fixes, the tool then picks the fix that occurs first by start index. This however, can produce several unwanted effects in the resulting code, such as applying multiple fixes for one error, or prioritizing changes by how the code is organized, instead of which fix is most likely to be applied. As written in #5, this is already done by services, and could be used to improve the output of the tool.

Original issue: iisaduan/ts-fix#7

Currently, this is most needed in createProject for when a project is unable to be created. There are a multitude of reasons this could happen, the most common being the options.tsconfig does not link to a valid tsconfig for a project. Knowing why a project could not be created would be helpful for troubleshooting.

Currently (b3cedc8), the following flags can be added or improved

• entries for custom --outputFolder should be tested to work on all OS and in bigger repositories with more complicated folder structures
• --file or similar, so the tool can be run on specified file(s)
• --verbose or similar, which describes which messages are outputted during runtime

There are important files that Microsoft projects should all have that are not present in this repository. A pull request has been opened to add the missing file(s). When the pr is merged this issue will be closed automatically.

Microsoft teams can learn more about this effort and share feedback within the open source guidance available internally.

Merge this pull request

Original: iisaduan/ts-fix#31

Need to test the file filtering. Right now, only filtering diagnostics by error codes is being tested

Currently ts-fix only identifies fixes being applied to the same span if they are consecutive.
It should be able to identify them even when they aren't consecutive.
It gets a little more complicated when multiple diagnostics are showing AND there are fixes being applied to the same span, how to handle that?