I would like to create node-red-contrib-context-project that behaves just like @node-red/runtime/lib/nodes/context/localfilesystem.js but uses the current project folder as dir option.
I would appreciate feedback on that idea already!
Problem from my first Context Store API discovery:
i have no access to settings which would give access to settings.get("projects").activeProject and the corresponding parent directory settings
i could not find a proper project api to trigger a commit if auto-commit is enabled
Recommendations for this?
Btw: would it be possible to use git-http transport by creating git-credentials and changing remote origin in the project folder or would it get reset by Node-Red?
What is the use case this is solving? Rather than jump to a solution, I'd prefer to understand the problem.
The projects directory is a git repository and contains the version controlled contents of the project. Putting the non-version controlled runtime state in that same directory doesn't fit my mental model of the world.
If have project A and save context X and Y and then switch to project B which also has a context variable X, it will pick up the X data from project A. In addition, it now had a context Y avialable.
Maybe the answer is that when you switch projects, the context variables shoud be deleted.
I see the flow as business-logic that acts in a (stored) context to give a project.
Currently i set inMemory context in an onStart-function node to keep context and flow together, but it feels wrong.
I use context for a kind of shared, flow wide, base setting. In my case it includes a tenant and some service endpoints belonging to that tenant. I run the almost same flow on different node-red instances by patching the onStart-function. Im currently moving to a custom wrapper embedding node-red where i can set the global inMemory context depending on the hostname i'm running on.
