Closed rellafella closed 3 months ago
I am curious about the "Failing" tests, not quite sure if they should be in here but rather listed out as issues...
What do you think about putting snapshot files next to source?
This is very easy to configure, I actually started it like this as it resembles the prettier-pug
approach, however having 2 files side-by-side where one is generated and the other is not, seemed like trouble. That being said, happy to move to that format if you would like.
I'll continue down this path for now, and once this is passing all tests i'll look at restructuring it.
Confirming though, you're happy with a snapshot file that is in a twig format instead of just exporting a string in a JS file?
I would suggest checking this out and having a bit of a play, perhaps even writing a new test or two. If you want me to remove the __snapshots__
dir and inline those snapshot files I can do that too.
Do you have an opinion on whether every test should have an associated snapshot? I think it would be useful for some tests just confirming for a "no-change" so instead of comparing to the snapshot it would just be testing expect(actual).toBe(code)
. This would be particularly useful for testing multiple values for options.
Confirming though, you're happy with a snapshot file that is in a twig format instead of just exporting a string in a JS file?
yes, having snapshot file as twig file will make it easier compare via diff
command or text editor.
This is very easy to configure, I actually started it like this as it resembles the
prettier-pug
approach, however having 2 files side-by-side where one is generated and the other is not, seemed like trouble. That being said, happy to move to that format if you would like.If you want me to remove the
__snapshots__
dir and inline those snapshot files I can do that too.
I don't have strong oponion on this. Either way is fine.
Do you have an opinion on whether every test should have an associated snapshot? I think it would be useful for some tests just confirming for a "no-change" so instead of comparing to the snapshot it would just be testing
expect(actual).toBe(code)
. This would be particularly useful for testing multiple values for options.
If the test doesn't change anything, I think it's fine not to include snapshot file.
Do you have anything to add? I think this is ready to be merged. We can deal other "inconsistency" on other PR. Before that, please rebase so I can fast-forward merge.
Thanks.
If you're happy with the change in the src/melody/melody-extension-core/visitors/filters.js file, then it should be all good to go. Agreed other inconsistencies and new tests can be done in a future PR.
LGTM.
Just before you merge, I have a POC to add some better type hinting with JSdoc for utilizing the function within tests and getting the twig options combined with the prettier options. I'll push this up then it should be ready.
:rocket:
Tests can't be configured with prettier options on a per-test basis #43
🏗️ this is still under construction but I wanted to get the draft PR in to explain a bit.
The way this is working at the moment in the pull request is instead of writing to a
jsfmt.snap.js
file, it is using theexpec.toMatchFileSnapshot()
method. https://vitest.dev/guide/snapshot#file-snapshots See the current status of the files to see how that looks.I have also got this working in a way that is more consistent with how it was setup before, by having one snapshot that will contain all of the tests. See the below screenshot for how that would work.
I could go either way on this, neither really change the workflow and the snapshot can be updated by passing the -u flag.