Adds `env: {}`

[ljharb]

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)

[fregante]

I went back and forth on that and decided to always add it to avoid having to document this specific behavior: everything is discarded except env, if it exists:

https://github.com/fregante/ghat/commit/89d198abac891178a25563fef9f6a35366bd833f#diff-e727e4bdf3657fd1d798edcd6b099d6e092f8573cba266154583a746bba0f346R31

I guessed it's easier to just always include it at the top and make it part of ghat’s own header. --verbatim is meant to specifically avoid these ghat-specific changes.

[fregante]

I'm not sure what consequences using that setting will have

--verbatim exclusively copies the files, no changes are made to them whatsoever, which means you can't customize it: https://github.com/fregante/ghat/blob/dda4c542cb1855f928aaf059790ad7401abd6c9c/lib.ts#L131

[fregante]

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

[ljharb]

re #27; I might also want to use the env setting, but still hide the comments - perhaps separate flags to control "env" and "comments"?

[fregante]

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.

[ljharb]

Very true, but I think that's fine - once i had them generated in this way, I'd use codeowners to ensure nobody else could modify them except the bot user that I set up to run #28 :-)

[fregante]

Can you open an issue requesting the new flag? Closing this and the comments issue

[ljharb]

Sure, #29