npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

esc-get-project-linecounts

v0.3.3

Published

Gets linecounts of node.js project for code and text, categorized as specified.

Downloads

25

Readme

esc-get-project-linecounts

Gets linecounts of node.js project for code and text, categorized as specified.

Example usage from cli

Simple

./get-project-linecounts.mjs --projectDir=/home/bob/my-project

Advanced

./get-project-linecounts.mjs \
  --projectDir=/home/bob/my-project \
  --specialDir=ignore,/logs \
  --specialDir=code,mockup-data,/imports/mockup-data \
  --specialDir=text,code-docs,/code-docs \
  --specialDir=scripts,scripts,/scripts \
  --specialDir=code,test-code,/imports/ui/pages/_Special/manual-component-tests,/imports/ui/pages/_Special/MultiPageTests,/imports/ui/pages/_Special/Tests

Example usage from code

import { getProjectLineCountsP } from 'esc-get-project-linecounts';

const { projectDir } = process.env;

setTimeout( () => getProjectLineCountsP({
  projectDir,                       // * required
  fmt: 'traditional',               // optional, can also be 'dense' or 'both'
  cssLibsA: ['reset', 'bootstrap'], // optional, or you get a lot of defaults (see code)
    specialDirsA: [                 // optional
    { type:'ignore'                      , pathsA:['/logs']                },
    { type:'code'   , label:'mockup-data', pathsA:['/imports/mockup-data'] },
    { type:'text'   , label:'code-docs'  , pathsA:['/code-docs']           },
    { type:'scripts', label:'scripts'    , pathsA:['/scripts']             },
    { type:'code'   , label:'test-code'  , pathsA:[
      '/imports/ui/pages/_Special/manual-component-tests',
      '/imports/ui/pages/_Special/MultiPageTests',
      '/imports/ui/pages/_Special/Tests',
    ]},
  ],
}).then( projectStatsS => console.log(projectStatsS) ), 100);

Example output

Project has [ 247,790 lines of code, 5,111 lines of mockup-data, 4,550 lines of code-docs, 1,850 lines of scripts, 16,004 lines of test-code ] (with traditional formatting)

Why it exists

Occasionally it's necessary to quantify a project's size in discussions or when considering doing things like fine-tuning an LLM on your codebase.

Traditionally code is formatted sparsely, but deciding how sparse or densely to format code is a matter of personal preference.

What is considered good formatting is subjective and contextual.

This script calculates how many lines a project's code would consume if it followed ChatGPT's recommendations for maximum-line-length and formatting etc in terms of traditional readability recommendations.

My personal (dense) coding style works out to be 23% of the number of lines of the traditional style that this script calculates.

Why write dense code?

Sometimes you only need to write a bit of code once and will rarely ever need to edit or read it again, and are happy to scroll sideways on that one occasion when you edit it if the need arises in future... rather than constantly scrolling up and down past code that you don't need to edit, hundreds of times.

Obviously I write relatively dense code because I've found that it improves my productivity significantly.

Ideally I want to see all of the code that's relevant for what I'm doing when I'm doing it.

So how densely I format a piece of code might depend on my perception of it's complexity and how soon or often I estimate the piece of code will need to be maintained.

Some people prefer to move cold code out into separate files, but that can also be problematic because then you have hundreds or thousands of additional files to manage. Then finding relevant files and switching files becomes a hassle, as well as setting up split-panes, managing where you position your split panes and how you resize them, every time you want to see some code that could simply fit on one or more dense lines.

Taking a logical argument to extremes

You can minify a 500,000 line project down to a single line by simply removing the \n characters. That's what happens when you deploy it.

So should you say that it's 500,000 lines or 1 line?

Maybe you like very dense code style. Maybe you say that it's 50,000 lines of code...

So how can we have a meaningful conversation about "number of lines of code?"

Separately quantify stuff that is not strictly 'code'

It seems reasonable to quantify the code up into test-code, scripts, mockup-data and code-docs separately from code.

The reasonable solution

The most sensible thing seems to be formatting code into standard traditional sparse format before measuring line-count.

Of course the rabbit-hole goes deeper

Really crap code might do something that could be more DRY by copy-pasting the same statements over and over again.

Even worse code might be excessively DRY making it unreadable and unmaintainable.

I am NOT suggesting 'more lines' = 'better code' = 'more impressive' = 'more work done'

This exists to produce a number to have an apples/apples conversation. I'm not implying LOC (lines of code) is a good measure of anything or that it's fit for some purpose etc.

If some lines of code doesn't add much value and I can delete it, I generally delete it. I generally err on the side of less code is better. But I err more on the side of not making inaccurate generalizations. Everything is contextual.

Why not use a linter to produce a line-count?

It's possible to do this with a linter but that linter is trying to produce perfect code, so that will most likely waste your time dealing with linter errors and it will consume a lot more CPU and RAM because it's actually changing the code or producing new perfectly executable code.

This script doesn't change the code or produce new strings of code at all. It simply calculates how many lines each line or feature would be in traditional formatting.

I'm reasonably confident it's plenty accurate enough for it's purpose.

PR's welcome

If you see any errors in my code please make a PR demonstrating the problem and your fix. A regex101 link might be helpful and relevant to include with your PR.

Project goals

  • Minimal dependencies: only 'glob'
  • Small and simple
  • Fast, low CPU and memory usage
  • Reasonably asynchronous

Installation

  1. npm install esc-get-project-linecounts

Say thanks

Star the repo https://github.com/softwarecreations/esc-get-project-linecounts

License

MIT