-
-
Notifications
You must be signed in to change notification settings - Fork 4.6k
Add --only-changed flag to CLI #5910
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
@g-harel Going back to the discussion you linked to in the related issue... Even though it seems no consensus was reached, what do you think about using (Similarly I'd love do see tools adopt |
Absolutely, I only used Do you know who would need to make the final call? |
|
@lydell Great! The whole idea is that it's a single ubiquitous directory to be shared by any tool or utility that wishes to cache some data, rather than polluting the root directory with multiple |
@mbrookes From what I remember using parcel, it doesn't use the folder in the way you outlined. It uses the entire folder as a cache and creates sub-directories with hex filenames to store the data. It looks like the two would not interfere, but given it's parcel's cache file, it might be best to avoid it. |
Personally I think it’s a missed opportunity. It would be naive of the Parcel devs to assume that a directory called |
Just playing devil's advocate on this one, if this is a CLI-only change, wouldn't it be better to have an external CLI tool that conditionally operates on files? e.g. say we had a CLI tool called $ smart-exec "**/*.js" -- prettier --write This would check a local cache before invoking the command after You could even wire it up to $ smart-exec "**/*.js" --ignore-path=.prettierignore -- prettier --write There's nothing Prettier-specific about the implementation, so it should be perfectly re-usable. Alternatively, if you wanted to do a bespoke prettier-cache tool, you could go zero-config ✨: $ prettier-changed This would behave exactly the same as the previous command, you could even build it on top of proposed I worry about adding too much frills to prettier-core (it's why |
I think this feature is important enough on large projects to be included with the "core" CLI. The current approach (in this PR) can be abstracted to a different tool, but it might make sense to eventually extend caching behavior (ex. I feel |
Any updates on this? What is the decision making process? |
if (context.argv["only-changed"] && !context.argv["write"]) { | ||
context.logger.error("Cannot use --only-changed without --write."); | ||
process.exit(1); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we should enable cache
by default and better add option --no-cache
(better DX, this do many tools. example jest
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought it might be best to avoid changing existing behavior silently, especially since this flag writes a file that needs to gitignored. I'll defer to the maintainers, y'all know best.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/cc @prettier/core
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we can do this for v2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, probably better to do it for v2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But what is problem implement --no-cache
by default?
return crypto | ||
.createHash("sha1") | ||
.update(data) | ||
.digest("base64"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe md4
(better use xxHash
, but xxHash
doesn't built-in in node 😞 ), sha1
is very slow, also we don't need strong here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We had a bit of a discussion about this on the issue and ended up finding that hashing is not a bottleneck in this case. I'm open to changing it, but I'm not sure it's worth adding a dependency.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okey, let's wait other feedback, for me md4
is best solution here, when you have really big codebase, it is increase perf around 5%
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea, some comments
This looks like a really nice addition. Would this also work when using |
Co-Authored-By: g-harel <gabrielj.harel@gmail.com>
b0e1335
to
a5e9f3f
Compare
Sorry about the delay, I was in exam season. I've changed the cache directory and switched to |
This is great addition to prettier. Thank you for taking the time to build this feature. I found myself wondering why python/black was so much faster than Prettier and it's because Prettier doesn't have this feature yet. What needs to be done before this PR can get merged? |
There is a discussion left unresolved about potentially having this behavior be enabled by default, which would need to be introduced in the next major version bump. Anything I can do to move this along? |
Storm prettier HQ and merge it yourself? 😆 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this the way it is! Good job!
expect(cacheContentsAfter).not.toBe(cacheContentsBefore); | ||
}); | ||
|
||
describe("ChangedCache", () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't have much of those unit tests in the repo, but this is fine
@g-harel Thanks for pushing this through. This will go out on the next minor release, so I'll wait a bit until 1.18 gets more stable, so we don't have to push any other patches Also don't worry about updating the branch, I'll take care of any conflicts before merge |
@@ -441,6 +443,18 @@ function formatFiles(context) { | |||
context.logger.log("Checking formatting..."); | |||
} | |||
|
|||
let changedCache = null; | |||
if (context.argv["only-changed"]) { | |||
const cacheDir = findCacheDir({ name: "prettier", create: true }); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/cc @g-harel need use || os.tmp()
https://github.com/avajs/find-cache-dir#findcachediroptions
It returns a string containing the absolute path to the cache directory, or undefined if package.json was never found.
In theory you can install prettier
globally and doesn't have package.json
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice catch! I've openned a PR with a fix (#6327).
closes #5853
Add an
--only-changed
flag to be used in conjunction with--write
to avoid re-checking files that were not changed since they were last written (with the same formatting configuration). These results are stored in the.prettiercache
file by default, but this can be configured using thePRETTIER_CACHE_LOCATION
environment variable.Here are some rough manual benchmarks using
docs/
directory)CHANGELOG.unreleased.md
file following the template.✨Try the playground for this PR✨