aklinker1/github-better-line-counts

Doesn't work with `yarn` out of the box

Araxeus opened this issue · 9 comments

Araxeus commented

image

The thing is, when you create a new yarn project using yarn init, it will create a .gitattributes like the following:

/.yarn/**            linguist-vendored
/.yarn/releases/*    binary
/.yarn/plugins/**/*  binary
/.pnp.*              binary linguist-generated

yarn.lock is not added to linguist-generated because git by itself doesn't count .lock files

so this extension should probably look for any .lock files by itself

aklinker1 commented

Not sure what you mean by "git by itself doesn't count .lock files", but you can just add yarn.lock linguist-generated to your .gitattributes and the extension should work.

So something like this:

/.yarn/** linguist-vendored
/.yarn/releases/* binary
/.yarn/plugins/**/* binary
/.pnp.* binary linguist-generated
+yarn.lock linguist-generated
aklinker1 commented

Oh, are you talking about how GitHub doesn't show the lock file's diff by default?

In this case, it's not showing the diff for performance reasons, since it's so large, it would slow down the page if it were visible. That's why it says "Large diffs are not rendered by default".

If you lockfile changes had been smaller, GitHub would have rendered the diff. GitHub does not have any hard coded filenames it treats differently in its diff view.

If a file is listed as linguist-generated in you .gitattributes, the label is changed to "Generated files are not rendered by default."

At which point the extension should properly exclude that file from the line counts.

Araxeus commented

I'm just asking if you could ignore the file even if it's not listed in the .gitattributes

Just ignore files that ends with .lock or -lock.*

aklinker1 commented

Hmm I'm not convinced that any file patterns should be hard-coded as generated. Just because yarn's .lock file is a generated file, doesn't mean all .lock files should be marked as generated. That said, I can't think of a .lock file that's not generated, but I don't know everything. I'd prefer to keep the extension as unopinionated as possible.

See #6 for custom file lists. We could have some suggestions for different languages and tools, like yarn, that auto-populate the custom list with patterns.

  • 👍1
Araxeus commented

lockfiles are always autogenerated, a quick google search will confirm that https://www.google.com/search?q=lockfiles 😋

  • Rust: Cargo.lock
  • Node.js: package-lock.json or yarn.lock
  • Ruby: Gemfile.lock
  • Python: Pipfile.lock or poetry.lock
  • .NET: packages.lock.json
  • PHP: composer.lock

but I do like the custom file list, tho I think lockfiles should be included by default in that list.
(that way if for some reason people don't like excluding lockfiles, they can disable that rule)

aklinker1 commented

I like that compromise! I'll put some lockfile patterns in a default custom list, that way yes, people could remove them if they wanted

aklinker1 commented

v1.5.0 will be released in a few days with this change.

  • 👍1
Araxeus commented

@aklinker1 It seems you have forgotten to update the firefox version

Might I suggest some auto publish action like https://github.com/PlasmoHQ/bpp ?

aklinker1 commented

Woops missed this one. I already have a script for publishing, just haven't setup an action yet. bpp doesn't support uploading source code to firefox, so that's not good enough. The problem was that I switch to a new publishing API for firefox, and it defaulted the channel to "self-hosted" instead of "listed" like it was before, so the update wasn't listed in the store. I fixed that, but then my authentication for chrome got screwed up and I didn't want to do it by hand...

But I've finally just published a new version by hand anyways lol. Should be signed and out soon.

  • 👍1