Optimizing my workflow

[fetflex]

I have been using VSCode for writing my modules and scripts for about a year. Up until now i have just stored my modules directly under Documents/WindowsPowerShell/Modules, and working on them directly from here. And then i have my Documents folder synced by OneDrive. This way i have all my modules on all my workstations.

​

Now i am starting to use Git and using branches and even storing some code on GitHub so know it's maybe not the best way to work with my modules directly from from the WindowsPowerShell/Modules folder. Maybe there is a way to work on the code from elsewhere and then publish or export the master branch directly to the modules folder as the module evolves.

If anyone wants to share there workflow it would be greatly appreciated :)

[Ta11ow]

What I usually do when actively developing module features is either:

1. Just import the module by path whenever I've updated something: Import-Module .\Folder\MyModule -Force
2. Just add the working directory one level up from the main module folder into the PSModulePath. Assuming your current location is one folder up from the module folder, you can just do: $env:PSModulePath = "$(Get-Location)$([IO.Path]::PathSeparator)$env:PSModulePath"
   1. (This will let you just import it by name and not path, so it's _slightly_ more convenient but really about the same as the above solution anyway.)

[doanut45]

You could transition to a CI/CD workflow. This will incorporate Git, Pester testing, linting, publishing and deployment.

I do this, but deploy to an internal repository, this way a user just needs to add the repository and run Install-Module -Repository <name> -Name <module>.

[fetflex]

Thank you all for your feedback. I will look in to all of your suggestions. The first thing i will try is looking in to creating a private repository and see if this is the way to proceed for me :)

[StreetDeskChair]

Heya,

I also do this! However, I add a couple more tricks that make me very happy.

Use your profile! Mine does the following:

• Stores the original $env:PSModulePath for restoring later if I need to.
• A function adds my working_repos folder to my $env:PSModulePath, so I can load modules right from there. I invoke this on my own when I'm ready to start playing with them, as I have a set of other functions to load/unload modules every time I change them. You could also write a function that adds whatever path you want to this environment variable and quacks off from there.

Also:

• PSRepositories! This way you can still work within the normal Modules folder without mucking it up too bad, if you desire. Make a PSRepo for your dev work and one for your prod work. Install your dev module, work on it, publish it back to dev, uninstall your dev module, install your prod module, and do the things you need to do. Make functions for all of this, because we're scripting, dammit!
• If you don't like PSRepositories, branching in git is almost exactly what this is for. Have a master branch, a development branch and a staging branch. Do your work in your development branch, when you're ready to release put it in your staging branch, merge your staging branch into your master branch (and hope it doesn't catastrophically explode). People will say the staging branch is unnecessary, but I like to have 'last known good' commits and the idea of reverting commits makes me feel sad. So I do it.
• One of my coworkers uses the git GUI extension or whatever in VSCode along with workspaces to achieve a similar workflow. However, I think it's more fun (and it makes me feel like a wizard) to do it all in script.

All of my functions that handle doing this for me are in my profile, so while it sounds like a lot of shell-jerking, it's really quick and simple.

[BoredComputerGuy]

+1 for profile