Structuring things for VSCode development

[shaneseaton]

First off, I really like where you are going with the project. Some top ideas in here, and I particularly love way poetry build-project is doing its thing.

I have a feel for how a workspace is hung together, but I am trying to workout how best to structure for all the other tid-bits of a project that don't fit cleanly into the structures you already have.

• .env files.
• dockerfiles
• .ci/cd
• vscode setting/launch configs

In the example you have at python-polylith-example. If I were a developer working on that fast-api project, I would probably want some launch.json setup for debugging. Do you have a sense of where that would live?

Is it possible all this stuff should just sit in the relevant project folder? I think vscodes like to have it .vscode folder at the root of the project. But then there is also the concept of vscode workspaces, so perhaps a .vscode in each project folder might be the way to go, pulled together with a vsworkspace for the polylith bits we need.

Perhaps some of this stuff lives outside of the workspace?

• repodir
  • workspace
    • projects
    • components
    • bases
  • otherthings?

I'd also like to think about this in the context of an ever-growing polylith repo with 100s of projects. What methods are scalable??

Sorry, a bit of a brain dump, but would love to hear from anyone who has either done this, or has opinions.

[DavidVujic]

Hi @shaneseaton, I'm happy to hear that you like the build-project feature!

I usually put the dev-related configs and setups at the root level of the workspace along with the folders that Polylith care about. You can think of it as a single-project environment, when it is about the developer environment related things.

For project-specific files and folders, it could make sense to have those in in the project folder. Such as a Dockerfile that is used in production or maybe a Makefile with project-specific targets. But that depends on how you have your CI/CD setup. It can also make sense to have a deploy or CI_CD folder att the workspace root, if you have a lot of shared setups between the projects.

From a Polylith perspective, it only cares about the bases, components, development and projects folders, and that means that you can structure your folders as you like.

[shaneseaton]

Thanks David, appreciate the quick response. Ultimately I think there no rules really, and its just about working out what works for your project. Would still love to hear any responses from the community on their setups, and hopefully when I work out something Im happy with I can report back here too.