Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Adds `env: {}`

See original GitHub issue

I ran npx ghat es-shims/Array.prototype.entries inside https://github.com/es-shims/Object.getPrototypeOf, and it added env: {} to the top of all my workflows, despite that not existing in the source. Can that be avoided?

(I realized that --verbatim will avoid this, but I’m not sure what consequences using that setting will have)

Issue Analytics

State:
Created 2 years ago
Comments:8 (5 by maintainers)

Top GitHub Comments

1reaction

fregantecommented, May 27, 2021

Currently the changes are:

adds env or move it up if it exists
adds comment
sets/excludes properties
if env/set/exclude are specified, the YAML file is parsed and rebuild by js-yaml, which will re-stringify it, essentially acting as a beautifier

--verbatim avoids all of this.

Since your intention is to leave any ghat-specific changes out, I think it’s best to leave --verbatim as is and introduce --no-header or something, which:

does not add env
does not add the comment

env would then be preserved in place.

This would be clean but honestly like for #28, comments and repositioning of env are made to help contributors know that these are generated files and need to be handled a certain way. Hiding them would inevitably lead to someone pushing changes and #28 automatically overriding them.

1reaction

fregantecommented, May 27, 2021

I suppose I could make one change:

allow --verbatim to be used with set/exclude
just show an warning instead of a fatal error: Verbatim was specified, but changes were also requested

This would also solve https://github.com/fregante/ghat/issues/27