@Zephyr

NEW DEVLOG!!

I’m terribly behind on a lot of work but that’s okay, lets keep going

So the call extraction is proving to be MUCH more difficult that I expected. Turns out, there are a lot of ways to call a callable symbol in javascript

But that’s fine, I’ve gotten most of it down now, just a few more cases to handle:

• the this keyword
• return values
• indirect parameter calls

After I’m done with call extraction, all that’s left to do is figure out how im going to save this graph, then I can use it to make my architectural linter CLI :D

Its time…. for another devlog :>

Okay so, here’s a concise list describing what I’ve accomplished:

• Make binding symbols to represent symbols which have been imported from another file
• Create aliases edges to connect binding symbols to the actual symbol, OR to connect namespace import symbols to the actual file being imported
• Create lookup / index tables for my data, then realize that i don’t need all of them during graph build time, then delete some of the indexes
• Major refactor of source code to use the new GraphBuilder class instead of manually collecting symbols/edges
• Write testttssssssss
• Clean up types (it was a mess, but its better now)

Now, I’m changing my main analyzer entry point to support multi-file tests without having to actually create the files (right now, it only supports code input of filepath input).

After that, i can FINALLY. AND I MEAN FINALLY. move on to call extraction :>

(and yes, this is yet another screenshot of the terminal / IDE cuz im still trying to extract data, theres not much to show )

NEW DEVLOGGG.

Okay so i’ve been super busy recently so not a lot of work done :> but i completed the export extraction, and also import extraction (which was surprisingly easy because turns out ts-morph does a lot of the heavy lifting for me)!

Was going to move on to call extraction, when i realized a few things:

1. I need to resolve my imports. How am i supposed to know what an imported symbol is referring to if they don’t have a symbol?
2. I need to create aliases edges for my binding symbols (which are technically dummy symbols used to represent the imported symbol that is being referred to), in order to connect them to their actual symbol.
3. I need lookup tables! :0 which i completely forgot about. So now I’ll be creating lookup tables as well via incremental updates. :>

After i resolve the above, i can FINALLY move on to call extraction

I’ve also decided to change what my project is for! Having a graph representation of an actual codebase is super powerful, so I’ll be using it to make some sort of architectural linter (like eslint but for architecture instead of code syntax)

This is what i have in mind currently:

layers: {
  api:          "src/routes/**",
  services:     "src/services/**",
  repositories: "src/repositories/**",
},

rules: [
  // Layer rules — explicit forbidden edges
  noCrossLayerCalls({ from: "api", to: "repositories" }),

  // Path rules — enforce mandatory intermediaries  
  mustGoThrough({ from: "api", to: "repositories", through: "services" }),

  // Cluster rules — graph-inferred boundaries
  noUnexpectedCrossClusterCalls(),
  allowCrossClusterCall({ from: "payments", to: "shared" }),
]

Obviously, its still a work in progress :> but i like where its going, will be working much more often hopefully

(P.S, the image shows my export extraction details)

NEW DEVLOG. Okay so:

I finished my symbol extraction and I have moved on to extracting exports :0 Unfortunately, all i have to show for it is STILL console output, but we’re getting there :>

• For the symbol extraction, i did a MAJOR refactoring of my code to use generator functions, and I’m much happier with the output now :D I also added extraction of some other symbols, and change the object extraction strategy to use a recursive approach (if i hit a property that contains an object, i recurse).

• For export extraction, I go over all export symbols that I found inside of the source file and then I handle their initializers. Basically: see what is being exported, and make an edge from the file to the export :>

Some hard cases that I have to handle include default exports and export specifiers. These aren’t exactly the same as other types of exports in the parsed AST, so I need to make sure some weird cases are working as well.

Next step is finishing my export extraction, writing a buncha tests, and then moving on to call extraction.

Okay devlog time :>

So far I’ve been really focused on accurate symbol extraction from the AST, I need to have enough information extraction about what functions are actually useful enough to qualify as a symbol, because I don’t want a symbol for some random .map() callback function!

Anyways, the image i’ve attached below is a dual view of the symbols im extracting. On the left, I’ve only got ids (for a quicker glance) and on the right I’ve got the full symbols for each id!

Also, after the first devlog, I realized the complexity of the project and instantly decided to write tests, so I’ve been doing that as well :> I don’t want to break something accidentally in the future without even knowing smh

So far, im creating a symbol for:

• non-exported variables that contain a function
• exported variables
• named classes
• named class’s methods
• named function declarations and arrow functions
• nested function declarations and arrow functions
• an object’s properties that are arrow functions/function expressions
• intermediate objects of a parent object that contains at least one callable descendant, that act as namespaces
• a function’s methods

Right now, I still need to collect a symbol for:

• default exports, whether named or not
• types
• enums
• interfaces
• Anonymous classes stored in a variable

After that, I need to write a couple of more tests, refactor my code a little (it’s pretty messy right now), and then move on to the call graph, where I’ll have to extract CallFacts (basically whenever a symbol is being called/referred to)

Okay! This is supposed to be a local tool that takes in a repository, creates a huge graph out of the entire thing (with relationships between imports, exports, function calls, etc), and then based on the graph, I’ll be able to answer questions like “what is this function for?”, or “What functions depend on this?”

The first step is scanning the repo (the easy part). Doing this was quite easy, since I just needed to use node’s fs module.

The next step is significantly more challenging: creating the graph. First, I’ll have to parse each file and get an AST out of it, then i’ll have to traverse it in order to collect all the information i need, along with all of the relationships.

Currently, this is the only output i can screenshot since im just trying to correctly parse and collect the AST nodes x-x but yes, i think its going to turn out well in the future :>