Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
includesec-erik opened this issue Jun 24, 2024 · 3 comments

Comments

@includesec-erik
Copy link

includesec-erik commented Jun 24, 2024

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
Copy link
Owner

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
Copy link
Contributor

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
Copy link
Owner

AlDanial commented Aug 3, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants