get-files.mjs strips trailing newline from committed file content

[jazzlyn]

get-files.mjs strips trailing newline from committed file content

Summary

Every commit made through this action strips the trailing newline from each changed file's content, even when the source file on disk has one. This silently corrupts files over repeated runs (missing EOF newline, and risk of a later append-style edit landing on the same line as existing content).

Root cause

In src/get-files.mjs:

const content = await $`cat ${path}`
...
const item = {
  path,
  content: `${content}`,   // <-- strips trailing newline(s)
  ...
}

content is a zx ProcessOutput. Interpolating it into a plain template literal (`${content}`) strips trailing newline characters from the captured stdout before it's sent as blob content to the GitHub Blobs API in src/commit.mjs.

Minimal repro (zx, independent of this repo):

import 'zx/globals'
$.verbose = false
const content = await $`cat f.yaml`   // f.yaml ends with "line1\nline2\n"
console.log(JSON.stringify(`${content}`))
// => "line1\nline2"   (trailing \n gone)

This strips all trailing newlines, not just one — a file ending in \n\n\n becomes line1\nline2 with none. So there's no way for a caller to work around this by padding the file before running the action; the fix needs to be in get-files.mjs.

Suggested fix

Read the file directly from disk instead of shelling out through cat + zx template-literal stringification, e.g.:

import { readFile } from 'node:fs/promises'
...
const raw = await readFile(path)
const item = {
  path,
  content: encoding === 'base64' ? raw.toString('base64') : raw.toString('utf-8'),
  encoding,
  ...
}

This avoids the ProcessOutput → string coercion entirely and preserves file bytes exactly, including a trailing newline or the lack of one.

Verification

• Unit-level: test with files ending in \n, \n\n, and no trailing newline; confirm produced content byte-for-byte matches the file on disk in all three cases.
• End-to-end: run the action against a test repo/branch on a file that ends with a newline, change a value, and confirm the committed file still ends with exactly one trailing newline (git show <sha>:<path> | xxd | tail).

[tyriis]

please test new version it should be fixed

v1.0.1 only the fix
and v1.1.0 with updated dependencies

[tyriis]

Review: Can the v1.0.1 change break non-UTF8 files?

Verdict: No regression introduced. The change from $ to readFile(path) + raw.toString('utf-8') does not break non-UTF8 files.

How both versions compare

Aspect	v1.0.0 ($cat``)	v1.0.1 (readFile)
Decoding	zx's $ uses TextDecoder("utf-8") internally	Buffer.toString('utf-8')
Non-UTF8 behavior	Corrupts invalid byte sequences → �	Identical — same corruption
Trailing newlines	Stripped by zx's implicit .trim()	Preserved (the actual fix)

Both versions decode content as UTF-8, so neither correctly handles non-UTF8 files. This is a pre-existing structural limitation, not a regression from this change.

The real issue with non-UTF8 files

The GitHub API only accepts encoding: "utf-8" or encoding: "base64". But the code passes through whatever file --mime-encoding returns verbatim. So for a binary or ISO-8859-1 file:

1. Content is raw.toString('utf-8') → garbled, with replacement characters
2. Encoding label says iso-8859-1 or binary → GitHub API will likely reject it

A proper fix would be to base64-encode the raw buffer when the detected encoding isn't UTF-8-compatible:

if (normalized === 'utf-8' || normalized === 'us-ascii') {
  content = raw.toString('utf-8')
  encoding = 'utf-8'
} else {
  content = raw.toString('base64')
  encoding = 'base64'
}

This would be a separate improvement, not related to the trailing-newline fix.

Bottom line: The v1.0.1 change is safe. The non-UTF8 concern is a pre-existing issue that would need a separate fix.