Skip to content
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

Replace resulting in an identical file has unusal behaviour #61

Closed
webstacker opened this issue Nov 1, 2018 · 5 comments
Closed

Replace resulting in an identical file has unusal behaviour #61

webstacker opened this issue Nov 1, 2018 · 5 comments

Comments

@webstacker
Copy link

Hi, I wrongly assumed that given a successfully matching regex, the file would be changed, even if that change resulted in an identical file. However, if the change would result in an identical file, nothing happens and it returns an empty changes array. The empty changes array implies that nothing matched, even though it did.

I assume it does this for performance reasons? If possible, can it always replace, or even return the changes as if the they had been made? This might partly address #42

If the current behaviour is expected, a note in the docs would be really helpful. Thanks

@adamreisnz
Copy link
Owner

Hi @webstacker, thanks for your feedback. Yes it looks like #42 will address this issue, allowing you to check for matches instead of replacements.

I will try to free up some time in the coming weeks to look into adding some of these features and do another major release. Will add a note in the docs for the time being to address this.

@adamreisnz
Copy link
Owner

Actually I think it's already pretty well documented here: https://github.com/adamreisnz/replace-in-file#return-value

But I'll update that after we've made the changes.

@webstacker
Copy link
Author

@adamreisnz I don't think I've been too clear, it's maybe the way we're looking at this...

I did read the docs but found them ambiguous:

If no replacements were made, the return array will be empty.

I assumed that if there were no replacements then there must have been no matches, but this isn't the case. Maybe another way to say it is; why are replacements resulting in identical results treated differently?

If the behaviour was consistent e.g. Any time there is a match, the replacement is made, then #42 wouldn't be an issue.

Hope that makes sense.

@adamreisnz
Copy link
Owner

Can you post some code and file contents with an example to clarify?

@adamreisnz
Copy link
Owner

In 4.0.0, we return a results array for each file that was processed, along with a count of number of matches and number of replacements. That should cover this use case and allow you to figure out if any replacements were made and if a file was changed or not.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants