@markbates I believe there is room for improvement here, but this addresses the primary concerns in #26

Where only the specific string prefixes that need adjustment are touched as part of the json marshaling process.

This is an improvement, but there are edge cases that will end up getting mishandled.

• Successive replacements means the output depends on the order they are applied when one prefix is the prefix of another, e.g. GOPATH of /go, HOME of /gopher, and a file path of /gopher/project.
• If GOPATH were /go, and the filepath is /gopher/project this will be mis-replaced, as it has the prefix /go even though the path is not actually inside GOPATH. To check this, you'd need to start checking for /go exactly or the prefix of /go/, and then handle the fact that the path separator differs on Windows.

I'd also have the conceptual issue of the MarshalJSON functions doing more than just serialization; the original code states that things are "fully re-hydratable", so you could marshal into JSON then back out again. This breaks that invariant by allowing the function to replace things. I don't know what impact that has.

Overall, I'd be curious what all of this metadata is being used for; what value is there in storing this info in the in-memory representation if it doesn't matter what it is? I believe the here library aids in finding files which is useful at runtime when no in-memory representation exists, but I don't know what use it has past that if it's going to be "wrong". But I'm new and I haven't read the entire codebase.

@markbates I initially wanted to just fix what the issue is, but am finding that this hepa filter, while a good idea, should be heavily optional. Perhaps a feature flag, or a variadic option func on the constructor.

While building in a docker container, the paths are already pretty generic and do not reveal much of the developers environment. Personally I would like to turn off these filters when building in a dockerized environ.

I will revert these changes to the hepa filter and propose a different PR for a variadic options func on the mem constructor for flagging the use of the hepa package.

It sounds like the filters are causing more problems then they’re solving at the moment. So, for now, let’s just remove them and then find a better way to deal with it.

@markbates g2g

@markbates I updated the README.md document example outputs to reflect the paths that will be generated without the hepa library

@markbates Let me know if there is any additional acceptance criteria to satisfy here.

Any chance this could get merged? I believe the current release is broken due to these filters (and I've kept my replacement for a while now).

@markbates Would you please merge this? Then we can begin the discussion around the original intent of the hepa filters for obfuscation of local dev environment details at a later date.