feature: Store the images in a common folder (not relative to the test file).

[stocksr]

I am using this plugin for component testing - and have my component test files next to my source files.
I would like to configure this plugin to use a central folder for storing the image files.

Reason 1 - My build process has to exclude those image files from the build/deploy of my app

Reason 2 - I would like to export all the diff images and golden images from a failing CI build as a build artifact so that I can review them.

I have tried setting the imagesDir property - but the only way that I could get this to work was by using ..\..\..\xxx style paths - and the depth is different for each file so this is unmaintainable.

[FRSgit]

Hey @stocksr,

Thanks for this suggestion, let's try to get it into the codebase!

1. We could add configuration option relativeImagesDir with default value of true (for backwards compatibility). Setting it to false would make imagesDir path being resolved against project root (or maybe again Cypress screenshots directory?).
2. We could just make imagesDir to be resolved against project's root directory when an absolute path is used (this would introduce a breaking change though). So, something like imagesDir: '/my-screenshots-dir' would create a directory my-screenshots-dir in the project root and place images within it.
3. We could introduce {project_root} and {spec_path} parameters which would be an aliases for: projects' root and path of the current spec file (relative to project root. So in your case you could write imagesDir: '{project_root}/my-screenshots-dir/{spec_path}' or imagesDir: '{project_root}/my-screenshots-dir' to get the images stored in directory my-screenshots-dir in the project root. In the first case - in nested directories that mimic the structure of your spec files and in the second case - as a bunch of images stored directly within my-screenshots-dir.

Currently I'm leaning towards option no 3 as it seems to be the most flexible and will allow future extensions. Also, the syntax is quite obvious in my opinion.

Please tell me what do you think about those 🙏

[stocksr]

I also think option 3 would be the most flexible, however to make it backwards compatible might be tricky if you have to support any possible current values.

Option 2 could work but if you go that route I would prefer a prefix like ~/ be used to mean project root relative rather than just / however a major downside of this this option would be losing the {spec_path} ability.

Thinking more about backwards compatible option 3 one option would be to introduce a new option with a default value of '{spec_path} {legacy_images_dir}' and deprecate the imagesDir option.
The other option I guess is to detect the use of a template in the string and if there are none add the {spec_path} prefix

[FRSgit]

Okay, I think we need to add a breaking change here. Good news though - there are 2 other "breaking" PRs in the pipeline, so we can release them soon 😄

Change of mind:
I like your idea - it will be better to deprecate imagesDir in favour of imagesPath option.
Why?
Because then we will be able to provide proper API under imagesPath and provide backwards-compatible support of imagesDir. This should make it easier to migrate for users who use imagerDir now (I have no data if there are any out there, but well 🤷 ). Also, I'll add deprecation info in the console and in the plugin typings - this should be enough.

And now about how the imagesPath could work:

1. When the relative path is passed in, it is being resolved agains project root,
2. User can use {spec_path} to save images in the same directory as the spec file (it'll be the path of the current spec file relative to project root).
3. Any absolute path will be resolved properly (need to remember both about support of unix and win filesystems).
4. Unfortunately it's very unlikely that we'll support other cases (like ~ as user directory on unix systems) - simply because the move-file package we use under the hood to copy screenshots over doesn't support those 🤷

This seems like a future-proof solution, let me try to create a PR and I'll ping you to test it out 😄

[FRSgit]

Hey @stocksr!

I've prepared a PR adding the feature we've considered together: #152
It has been released on NPM under version 2.4.0-alpha.0
Can you give it a try please and write your feedback under the PR? 🙏 I need at least a confirmation that it resolves your issue 😄

[stocksr]

Many thanks for this @FRSgit - this exactly solves my requirements.

[FRSgit]

Hey @stocksr , this feature was released in the new release - 3.0.0! 🎉
Closing this issue as resolved - please open new ticket if you find any issue 🙂