You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Stumbling across this in a Yeoman generator in repos with Makefiles. When generating files that already exist, even if the generated contents are identical to those on disk, they are still unconditionally written with updated timestamps.
I can see use cases for wanting that timestamp updated anyway, so I don't strongly suggest unconditionally skipping this as a default. Perhaps something like forceWrite: false should be an option that can be passed to .copy/.copyTpl/etc.?
I think it'd make sense to just skip the write if the content is the same; I don't quite see the value of updating the file timestamp. Seems you already dug into the relevant code, would you be willing to send a PR?
Stumbling across this in a Yeoman generator in repos with Makefiles. When generating files that already exist, even if the generated contents are identical to those on disk, they are still unconditionally written with updated timestamps.
I can see use cases for wanting that timestamp updated anyway, so I don't strongly suggest unconditionally skipping this as a default. Perhaps something like
forceWrite: false
should be an option that can be passed to.copy
/.copyTpl
/etc.?.copy
calls.write
here:mem-fs-editor/lib/actions/copy.js
Line 66 in a75c5e7
File state unconditionally set as
modified
here:mem-fs-editor/lib/actions/write.js
Line 13 in a75c5e7
Which is checked here before writing:
mem-fs-editor/lib/actions/commit.js
Lines 42 to 43 in a75c5e7
The text was updated successfully, but these errors were encountered: