AlDanial / cloc

cloc counts blank lines, comment lines, and physical lines of source code in many programming languages.
GNU General Public License v2.0
19.39k stars 1.02k forks source link

Differentiation of client-side vs. server-side code for langs where both can be defined? #837

Open includesec-erik opened 3 months ago

includesec-erik commented 3 months ago

There are likely other languages/frameworks, but the client-side/server-side paradigm with JS/TS is the most common place this use case is present.

Server-side Express: Looking for require('express'); would signal a NodeJS/Express server-side component.

// Import the express module
const express = require('express');

// Create an instance of an Express application
const app = express();

// Define a port number
const port = 3000;

// Define a simple route that sends a JSON response
app.get('/api/data', (req, res) => {
  const data = {
    message: 'Hello from the server!',
    timestamp: new Date().toISOString(),
  };
  res.json(data);
});

// Start the server and listen on the defined port
app.listen(port, () => {
  console.log('Server is running');
});

Current cloc....

> cloc express.js
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
JavaScript                       1              4              5             13
-------------------------------------------------------------------------------```

New cloc....

> cloc express.js
-------------------------------------------------------------------------------------------------------------
Language                                                        files          blank        comment           code
-------------------------------------------------------------------------------------------------------------
JavaScript(Express Server-side)                       1              4              5                          13
-------------------------------------------------------------------------------------------------------------

Client-side NextJS: For situations such NextJS 13 and later (released Oct 2022), would it make sense for cloc to differentiate the kind of code similar to the example output below?

In Next.js, the "use client" directive is necessary for all client-side components in order to specify that the component should be rendered on the client side rather than the server side. This directive was introduced to help developers explicitly distinguish between server-side and client-side rendering, particularly in the context of Next.js 13 and its new app directory structure.

// ExampleComponent.js
"use client";

import { useState, useEffect } from 'react';

const ExampleComponent = () => {
  const [count, setCount] = useState(0);

  useEffect(() => {
    console.log('Component mounted');
  }, []);

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => setCount(count + 1)}>Increment</button>
    </div>
  );
};

export default ExampleComponent;

Current cloc...

> cloc ExampleComponent.js
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
JavaScript                       1              6              1             15
-------------------------------------------------------------------------------

New cloc....

> cloc ExampleComponent.js
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
JavaScript(NextJS Client-Side)                       1              6              1             15
-------------------------------------------------------------------------------

Concluding thoughts on this feature's potential.... Pro: Differentiates between client-side and server-side code, those who are counting code would be more aware of the code in the code base and what the composition of it is as a counted item

Con: May have false positives due to other JS frameworks doing their silly things and having collisions with keywords used in Express and NodeJS.

Consideration point: Make it an optional feature to maximize the pro and minimize the con?

If determining the composition and context of the code cloc is counting is outside of the purpose of the tool, no worries, but wanted to bring this idea up as a quick search of past enhancements on github issues didn't mention anything like this concept.

AlDanial commented 3 months ago

It's an interesting idea but will take some thought to implement cleanly. At the moment cloc uses per-language filters to define what's a comment. Possibly the filter concept could be extended to additionally identify flavors (ie client or server). I'll need to think on this.

Aerek-Yasa commented 2 months ago

A common differentiation in many languages is between test-files and non-test-files. If cloc is going to be modified to allow differentiation for some categories, then testing is an obvious target. For some languages this would be trivial to detect using the filename alone. Typescript test files typically end in .test.ts or .spec.ts. Golang test files typically end in _test.go.

~Aerek

AlDanial commented 1 month ago

I'm liking this idea increasingly more. Before I start work on it though I need to tackle the long overdue feature of tracking git file renames (#765, #800). So it will be a while.