You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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');
});
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.
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.
The text was updated successfully, but these errors were encountered:
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.
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.
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.
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.Current cloc....
New cloc....
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?
Current cloc...
New cloc....
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.
The text was updated successfully, but these errors were encountered: