Closed samestep closed 2 years ago
I'm guessing that the cache is there for a reason, so I want to make a pull request that changes the cache from being persistent to being session-scoped, so for instance, it could be cleared by Developer: Reload Window. However, I'm not sure how to write a test for this; I was going to put it alongside the existing getPrettierInstance
test suite, but I'm guessing that those all take place within a single VS Code instance session. For now I'll just make a pull request without an automated test.
It seems like this could be resolved by simply reverting 03b65aa632eda7ad9ac714f2709daa7b1d8819fe?
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Summary
Currently this extension caches the path to Prettier for each file in a VS Code workspace:
https://github.com/prettier/prettier-vscode/blob/da5b5ebfc4858a96e4ee6bc877a4026107b0fcab/src/ModuleResolver.ts#L307-L312
Sometimes the correct Prettier path for a given file changes, such as when using Lerna and removing a dependency from a package in favor of using a repository-wide version of that dependency; see https://github.com/penrose/penrose/issues/847 for an example of this exact situation.
When this happens, this extension continues trying to find Prettier in the old location rather than re-running
findUp.sync
to get the correct location. This fails with an error that prints a stack trace in the logs, as a result of which the extension incorrectly defaults to using the bundled version of Prettier instead of the repository-local version.Github Repository to Reproduce Issue
https://github.com/samestep/prettier-vscode-caching
Steps To Reproduce:
yarn
from the repository root.packages/foo/index.js
.git switch consolidate
.rm -r packages/foo/node_modules/
from the repository root.yarn
again.Expected result
The file should remain unchanged at the last step. Switching to the
consolidate
branch removedprettier
from thedevDependencies
ofpackages/foo/package.json
, meaning that this extension should instead keep going up two more directories to find it in thedevDependencies
ofpackage.json
in the repository root, so it should use Prettier version 2.2.1. Indeed, this is exactly what happens if you checkout theconsolidate
branch first, before using VS Code to run Prettier onpackages/foo/index.js
from branchmain
, because at that point the cache has not yet been populated.Actual result
An error appears in the logs (see below), and the file gets reformatted according to Prettier 2.5.1 bundled with this extension (which happens to give the same result as Prettier 2.3.0 in this case).
Additional information
VS Code Version: 1.63.2 (Universal)
Prettier Extension Version: 9.1.0
OS and version: macOS Big Sur 11.6.2
Prettier Log Output