Should exclude Lock files like Cargo.lock

[futurist]

Describe the bug
What count in rust project, the Cargo.lock file also counted.

Like: https://github.com/cgag/loc

To Reproduce

1. In Any cargo based rust project, run scc
2. The result show Cargo Lock lines.

Expected behavior
Cargo.lock is auto generated file, should not be counted.

Desktop (please complete the following information):

• OS: macOS 10.15.5
• scc version 2.13.0

[boyter]

This is one I am on the fence about. I actually have it set to count cargo.lock as a filetype which might exist in a project. Because even though its auto-generated its part of the project.

It actually follows the same logic that say rg or ag would, because they both would look through the file,

$ rg 58fb5e95d83b38284460a5fda7d6470aa0b8844d283a0b614b8535e880800d2d
Cargo.lock
264:"checksum aho-corasick 0.7.6 (registry+https://github.com/rust-lang/crates.io-index)" = "58fb5e95d83b38284460a5fda7d6470aa0b8844d283a0b614b8535e880800d2d"

Generally I suggest using a .ignore file if you would not want to count this file.

Although I am prepared to be convinced otherwise.

[futurist]

It's different software as rg or ag, they do search and scc do count, count people's works. If Cargo.lock can be count, then is it right that many other machine generated code, like yarn.lock, pubspec.lock, Podfile.lock, package-lock.json...

ag will search it mostly because this file sometimes will be pushed(for CI/CD etc.), and sometimes should be ignored:

https://dev.to/gajus/stop-using-package-lock-json-or-yarn-lock-3ddi

The origin of this misuse is NPM documentation. It should instead explain that package-lock.json should only be committed to the source code version control when the project is not a dependency of other projects, i.e. package-lock.json should only by committed to source code version control for top-level projects (programs consumed by the end user, not other programs).

And most of lock file also has below lines likewise:

yarn.lock
# THIS IS AN AUTOGENERATED FILE. DO NOT EDIT THIS FILE DIRECTLY.

[boyter]

Convinced. Pushed into master. Closing down.

[LinusU]

@boyter would it be possible to also exclude package-lock.json out of the box? For the same reason as as above

[boyter]

Hmm that is just a JSON file though. If you need this now, add an exception in .ignore and that should take care of it.

Have you got a sample of what it has in the header? Might be able to use that to exclude.

[LinusU]

I looked at that but there wasn't any useful header I think:

{
  "name": "name",
  "version": "0.0.0",
  "lockfileVersion": 1,
  "requires": true,
  "dependencies": {
    ...
  }
}

I'm currently passing -M package-lock.json to work around it, but I would love it if this specific file would be ignored by default ☺️

[itay-grudev]

@boyter the package-lock.json is a for all practical purposes equivalent to Cargo.lock. The naming is now industry standard and can be safely ignored.

Have you got a sample of what it has in the header?

It's a JSON - doesn't really have a header, but here are some common fields that you can test if they exist at the root level:

{
  "name": "",
  "lockfileVersion": 3,
  "requires": true,
  "packages": {}
}

For a tiny 500 line project the package-lock.json adds 7000 lines of code and $200,000 to the estimation to an otherwise $9k project.

[boyter]

I guess we could add something similar to the scc --exclude-dir argument and populate it with some of these cases. Starting with package-lock.json.

How does scc --excluded-file sound for this?

[itay-grudev]

@boyter Yes - to both. We could really use such an argument, but also I strongly believe that generated files like package-lock.json should be excluded by default, as counting them just doesn't provide useful information. In fact it skews total estimations in the wrong direction.

[itay-grudev]

A more convention-over-configuration approach with sane defaults would work best.

[NathanielHill]

@boyter would second here that for JS/TS projects package-lock.json is functionally equivalent to Cargo.lock so should be excluded by default for consistency with previous decision.

[NathanielHill]

Awesome tool btw! For extra context, it adds 50ksloc and $2 million to my project estimate. It's not hard to add to .ignore or -M package-lock.json (because I don't want to commit a .ignore for a single line)... but would be nice if it just worked for TS/JS based projects

[boyter]

Ill ensure this gets into the next release.

[boyter]

Done. Ignore files, gitignore files and the following package-lock.json,Cargo.lock,yarn.lock,pubspec.lock,Podfile.lock are now ignored by default in the output.