Hi there,

Thanks for this handy module. I've been using it within a shared build tool with great effect. We're looking into moving into a Yarn Workspace setup and I noticed that this serializer does not handle normalization of the yarn workspace root path.

For example, in a non-workspace setup a path that was ~/code/single-project/node_modules/foo/foo.js would correctly normalize to <PROJECT_ROOT>/node_modules/foo/foo.js

However, in a Yarn workspace this may resolve to to ~/code/workspace/node_modules/foo/foo.js (the project in this case lives at ~/code/workspace/packages/single-project), which gets normalized as <HOME_DIR>/code/workspace/node_modules/foo/foo.js. Ideally, this would be relative to the workspace root (something like <WORKSPACE_ROOT>/node_modules/foo/foo.js) so that our tests are not dependent on a specific project location.

I took a very quick pass at this in https://github.com/tribou/jest-serializer-path/compare/master...nason:yarn-workspace-support?expand=1. It seems to be working for me, but wanted to get your thoughts on this before going any further.

when running jest-serializer-path I've noticed that \\" quotes are being converted when they aren't really paths.

https://github.com/gatsbyjs/gatsby/pull/10964/files#diff-72f7b704a71888b35ecd3bff4eec3195

I'll make a PR and test cases for it 👍

This doesn't seem to be working on windows mainly because of https://github.com/tribou/jest-serializer-path/blob/master/lib/index.js#L5

you have an indexOf for /node_modules/ but on windows these are double backslash example C:\\git\\obg.tools.packages\\node_modules

I use the \ in some of my snapshots. i never test on windows so i don't need the character to be replaced. would be nice to be able to turn this functionality off somehow

Is there a reason __dirname is used to find the project root instead of process.cwd()? This is causing some issues with a tool I'm using and I was wondering if you'd accept a PR that switched to process.cwd()?

When an object contains a property with value foo/tmp/bar, the snapshot will have foo<TEMP_DIR>/bar, which is unexpected. I was expect that only strings starting with /tmp would get replaced.

Firstly, wonderful concept and glad that someone has taken the time to do this. Thank you for that.

Surprisingly though, using this has unexpected results as it modifies the object being tested after the expect has been executed. That's not at all optimal as objects can still be used down the pipe. If this project is going to be opinionated about that (not a bad thing necessarily) then baking some manual mechanism for restoring the object would be preferred.

This code illustrates the problem:

it('should test', () => {

  const result = getSomeObj({ ... }); // { path: '/Users/user/code/myproject/lib' }

  expect(result).toMatchSnapshot();

  // at this point the snapshot written is correct, and result.path is '<PROJECT_ROOT>/myproject/lib'
  // however, the result object has now been mutated, and silently no less

  // the following will now fail as the path has been mutated and does not exist
  fs.writeFileSync(path.join(result.path, 'myfile'), 'myfile data', 'utf-8');

});

I'd wager that this is a common problem. We're exploring using this module as a default for the webpack-contrib org, which means it'd be part of every official webpack loader and supporting development module. Unfortunately in it's current form, mutating the tested object is going block our use since we do quite a bit after a snapshot test for many modules.