@Zephyr

Final devlog… forever (turning 19 tomorrow, so this is the last devlog :D) I finally released the beta!!! We got the GUI running (only for grid merge so far) but it works! I added state management inside of local storage so changes dont keep disappearing, and I also added the export button functionality! Have fun!

LADIES AND GENTLEMEN, GUESS WHAT TIME IT IS. (devlog time )

First of all, I added a summary and continue section in the sidebar on the right to provide a more “guided” user experience I guess you could say. :>

Then, I also, changed the left sidebar to make things simpler; there will only be a single page for all merges now. :D

And the rest? I’ve just been adding fields in the merge page for all the different settings the user can mess around with (there’s a LOT). Once I finish with that, I’ll be actually rendering the final product to the user so they can see what they get once they export!

DEVLOG!

Okay SO. Image selection is now complete: users can choose which images they want to proceed with. I also added shift-clicking, so users can select multiple images more easily (see the video!).

Next: Responsiveness ✨ I made the main sidebar responsive so far, so the layout of the page seems to be working fine, at least up until around the sm/md breakpoints. I’ll also have to handle making the secondary sidebar responsive in mobile screens.

Finally: Light mode and dark mode! FINALLY, I added a button to toggle between the two, should be much easier to design either theme now :>

Next step is to add a bar on the bottom of the screen which helps guide the user’s next step. Then we can start with the merge pages!

NEW DEVLOG!

Alright ladies and gentlemen, I’ve made a layout for the images, where the user can choose either a compact layout or a normal (slot-like) layout. I’m using animejs for the smooth, snappy animations, in case anyone out there was curious :>

Now, I need to allow the user to select which images they want, then, I’d also like to add some sort of utility bar on the top/bottom.

Then, I’ll use those images to make the merge pages! wish me luck :>

OKAY. Some progress (and some setbacks :>)

So I’ve worked on the uploaded design, as well as the backend that was meant to write the file to the /tmp directory. The problem I needed to solve was to figure out a way to store the files on the backend that didn’t involve writing duplicates to the user’s disk.

This is a very difficult task, because I can’t get file paths from the input field in the frontend, only the filename and file content (and some other unrelated details).

Solution? Implement a different system that DOESN’T involve file uploads :D

If I just use the directory im in when the user runs the command to start the loopback GUI, I can define a “project scope” in a sense, where I only try to use images in that directory. This way, it’s up to the user to choose which folder they want to use as their project. :>

So now I need to refactor BOTH my design and backend to support this HA. Awesome

Initial Devlog!

Okay so: I’m back. :>

I’ve started working on a project I’ve been meaning to do for a while, called “Pixeli”, a CLI for merging images together! I actually already made this project before, and now I’m adding a GUI to it.

Currently, I’m working on the file upload and rendering mechanisms. :D Will also be doing dark mode :0

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 :>