Architecture: ecolog future

[philosofonusus]

When I initially created this plugin. I wanted to make simple but a very good tool to work with env variables, I hated how I worked with env variables, I needed to constantly switch to env file and then back to my actual code to know if an env variable actually exists. This plugin initially was made for me to train how to do plugins in general and with a passion for a change.

I built Ecolog because I wanted to make working with env variables less painful. But now I see that to really solve this problem, we need to understand not just where env variables are accessed, but how they flow through the codebase.

Our current regex-based pattern matching approach for environment variables has limitations when dealing with variable assignments and references. For example:

// Currently supported - direct env access
const url = process.env.DATABASE_URL;

// Not supported - variable reference
const dbUrl = url;

// Not supported - named imports
import { DATABASE_URL } from '@env';
const connection = DATABASE_URL;

The plugin can't track environment variables once they're assigned to other variables or imported through module systems. This makes features like EcologPeek and EcologGotoVar less effective in real-world codebases where environment variables are often:

• Assigned to variables for reuse
• Imported from configuration modules
• Passed through function parameters
• Destructured or transformed
• Used across multiple files

The Solution I'm Considering

I think we need to create an LSP proxy that can:

1. Creating a new LSP proxy layer that intercepts definition/reference requests
2. Building a reference tracking system that maps variables to their env var sources
3. Modifying the peek functionality to check both direct env vars and referenced vars
4. Adding workspace symbol support to track exports/imports

The plugin future

I'm going to focus now on stability of existing features to go from alpha to actually stable codebase, meanwhile I will introduce more QoL features and other commands/improvements, will also try to make more providers for languages. Basically everything stays the same for you those features will be transferred eventually to the new codebase.

My goal will be to achieve this big milestone. But I'm not that good at lua and neovim specifics in development in general. I want your help to let me know even whether this solution is any good or help me with development.

Any of your contributions to the project are going to be very helpful to achieve this big dream. Thanks for the support, prepare for what is coming