agent session
This commit is contained in:
@@ -0,0 +1,32 @@
|
||||
# Winos-config DSC interop layer
|
||||
_Exported on 12/18/2025 at 16:27:56 EST from Cursor (2.2.36)_
|
||||
|
||||
---
|
||||
|
||||
**User**
|
||||
|
||||
@README.md I am trying to build a winos-config tool with effect-ts and dsc with winget
|
||||
|
||||
@src/bin.ts
|
||||
|
||||
The overall idea of the app is, is you can define the state you want your windows machine to be in using typescript.
|
||||
|
||||
The typescript def will get converted to dsc, then dsc can apply the config to the system.
|
||||
|
||||
The future goal is that a user of this project is that a user could track their desired:
|
||||
- installed programs
|
||||
- some basic system settings
|
||||
- Their theme settings
|
||||
|
||||
all within the typescript config with strong typing and the ability to create their own abstractions (with ts functions and what not)
|
||||
|
||||
I think we should start by getting a really solid dsc to typescript interop layer then we can build some helpful abstractions on top of that.
|
||||
|
||||
Right now I am only generating ts code for a few of the basic dsc types. I believe I need to modify my scripts so that it actually generates the ts code based on all of the dsc resources available on the machine.
|
||||
|
||||
This is a bit of a design choice, but I think for now we can generate ts defs for all of the dsc resources on this dev machine even though a future user of this lib may not have some of those dsc resources on their machines.
|
||||
|
||||
I believe the next steps will be:
|
||||
- explore the dsc cli to see how we can output json schemas for the dsc resources
|
||||
- refactor our scripts so we can generate types based on those
|
||||
|
||||
Reference in New Issue
Block a user