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
The current implementation for the diff is a quick best effort implementation and we have to change it to Myers algorithm or similar to properly detect these changes without a bad runtime.
There has been no activity on this feature request for 5 months. To help maintain relevant open issues, please add the
never-staleIssues and PRs exempt from automated stale handling.
label or close this issue if it should be closed. If not, the issue will be automatically closed 6 months after the last non-automated comment.
For more information on how the project manages feature requests, please consult the feature request management document.
After spending A LOT of time looking around and trying things, I don't think implementing any standard diff algorithm is going to be perfect for us. Why? Because we have a couple of edgecases which would deviate from any diff algorithm, ending up into something custom anyway:
and, if you pay enough attention, in actual (the first array), creator: '123', has a trailing comma, which is not present in the second array, that's why the diff with the already implemented diff looks the way it looks, hence the creation of this issue.
The naive solution to this problem is to do something like this:
// Remove trailing comma from each lineif(typeofactual==='object'&&actual!==null){for(leti=0;i<actualLines.length;i++){actualLines[i]=actualLines[i].replace(/,$/,'');}}if(typeofexpected==='object'&&expected!==null){for(leti=0;i<expectedLines.length;i++){expectedLines[i]=expectedLines[i].replace(/,$/,'');}}
which is NOT ideal. The problem I am pretty sure should be resolved in the inspect function, but I am not smart enough to both fix the issue and not break anything else in the codebase.
in the current implementation there is a gazillion of exceptions just for proper formatting the output: object too nested? hide part of it. Too many consecutive unchanged lines? crop some of them. The terminal is too narrow? ellipse some lines.
I am not sure the whole effort of implementing all these things into the new algorithm is worth it.
it behaves a little bit differently than before, but it is working nice so far. I still have many broken tests I need to fix, but it is a working solution.
The main problem I am having is how to tackle point 1 of the issues I mentioned before; if you guys have any idea or suggestion, you know how to find me 😄
Activity
alepefe commentedon Feb 12, 2024
It happened to me as well.
BridgeAR commentedon Feb 12, 2024
The current implementation for the diff is a quick best effort implementation and we have to change it to Myers algorithm or similar to properly detect these changes without a bad runtime.
oriongonza commentedon Feb 13, 2024
Would a fix to this get added to node 20?
github-actions commentedon Aug 12, 2024
There has been no activity on this feature request for 5 months. To help maintain relevant open issues, please add the never-staleIssues and PRs exempt from automated stale handling.
label or close this issue if it should be closed. If not, the issue will be automatically closed 6 months after the last non-automated comment.
For more information on how the project manages feature requests, please consult the feature request management document.
oriongonza commentedon Aug 12, 2024
bump
puskin commentedon Sep 4, 2024
After spending A LOT of time looking around and trying things, I don't think implementing any standard diff algorithm is going to be perfect for us. Why? Because we have a couple of edgecases which would deviate from any diff algorithm, ending up into something custom anyway:
I actually ended up implementing the myerDiff algorithm myself in the
assertion_errorand (with some caveat) is working fine:There is a couple of problems tho:
createErrDifffunction, we do this:which converts the input:
to
and, if you pay enough attention, in
actual(the first array),creator: '123',has a trailing comma, which is not present in the second array, that's why the diff with the already implemented diff looks the way it looks, hence the creation of this issue.The naive solution to this problem is to do something like this:
which is NOT ideal. The problem I am pretty sure should be resolved in the
inspectfunction, but I am not smart enough to both fix the issue and not break anything else in the codebase.I am not sure the whole effort of implementing all these things into the new algorithm is worth it.
To fix the issue OP reported, we need to tweak this check: https://github.com/nodejs/node/blob/main/lib/internal/assert/assertion_error.js#L235
right now only works if
expectedhas the trailing comma, it does not check if theactualhas it.I could make that change and it should solve the issue, without adapting the algorithm I built to cover all the edge cases.
What do you think?
puskin commentedon Sep 4, 2024
actually, I worked a lot on it today and for such an example:
this is what I get back with the new algorithm:
it behaves a little bit differently than before, but it is working nice so far. I still have many broken tests I need to fix, but it is a working solution.
The main problem I am having is how to tackle point 1 of the issues I mentioned before; if you guys have any idea or suggestion, you know how to find me 😄
19 remaining items
assert: make assertion_error use Myers diff algorithm
assert: make assertion_error use Myers diff algorithm
assert: make assertion_error use Myers diff algorithm
assert: make assertion_error use Myers diff algorithm