[feature] Extend docker scaffold configuration with workspace files filters

[artsiommiksiuk]

Is your feature request related to a problem? Please describe.

Seems like docker scaffold is js oriented and hardcoded, as it is copying js related config files and there's no way to specify which files belong to workspace. There's only sources config for that, and no filtering for "config" files.

This doesn't match the statement of moon being language agnostic tool.

My use case - I have a mixed env with js and python and doing migration to moon. Both js and python are quite mixed with each other on the files structure level, and default behaviour of docker scaffold just doesn't work for me at all.

Describe the solution you'd like

To overcome this we can have just docker.scaffold.workspace.include/exclude filters, which will allow users to have config per project and per tech stack. I'd also change then ``docker.scaffold.includetodocker.scaffold.sources.include/exclude``` for symmetry with workspace.

Describe alternatives you've considered

I don't see any. Idea with scaffolding only configs under moon's supervision is quite good I think.

[artsiommiksiuk]

As far as I can tell, it is indeed hard choice on languages currently:

https://github.com/moonrepo/moon/blob/master/crates/app/src/commands/docker/scaffold.rs#L77

[artsiommiksiuk]

Ah, I found that this workspaces files include list can be set on workspace level config:

https://moonrepo.dev/docs/config/workspace#scaffold

But, I still have a need to exclude files (global include only list captures too much), as in not very clean repos (or not yet decomposed) it's hard to specify global include without exclusion list.

So the proposal still holds: To have include/exclude lists for both sources and configs specification on package level as well as on workspace level.

[milesj]

What do you mean by config exactly? If you're referring to package.json, then it is required to copy from all projects, regardless of language. Otherwise, package managers don't function correctly, especially when using workspaces.

moon's implementation is meant to solve the common use case with the least amount of configuration. Requiring users to explicitly/granularly configure every part of the workspace/project skeletons isn't our goal.

[artsiommiksiuk]

What I mean, is that there's a lack of granularity in configuration here. Specification of the files for bootstrapping on whole monorepo level is fine, what is missing, is to granularry configure additional files for bootstrap per project. E.g. I have a non default js + python combination, where for python I have to build it's dependencies from sources.

Specifying in workspaces those sources via glob includes too much files (like **/*.c) would do, and also it would include them for other packages, so I'm ending up with way more files than I need to. One way to counter this probably would be globbing per project path (like libs/lib1/vendor/**/*.c).

Instead what would be nice is to just have this option available per project, which will be merged with workspace level defined globs as well.