Support multiple .forceignore files in a project

[shetzel]

This discussion is based on the issue raised here: .forceigore in submodules overrides parent

Question 1: How desirable is this feature?

Question 2: How should this be supported? The assumption is, "do what git does", but let us know if you have other ideas. Keep in mind that this behavior happens within the @salesforce/source-deploy-retrieve library that doesn't require a project.

Question 3: What are your usecases?

[k-capehart]

Having it behave the same way as .gitignore files seems like the best option to me. It's intuitive and I can't think of any reason why it should be different. Although I'm interested in what the complications are that you mentioned for the @salesforce/source-deploy-retrieve library.

[shetzel]

The complications are:

• The SDR library does not need to operate within a DX project whereas git always operates within a git repo and can assume things based on that. E.g., a project root directory cannot be assumed.
• The current code in SDR applies a .forceignore for each metadata component and that is where searching up begins. That behavior has not changed for many years and might be difficult to modify.
• Making this change could break customers relying on the current behavior, so it would need to be done in a backward compatible way.

[azlam-abdulsalam]

@shetzel There are situations when we want forceignores have to different behavior while building a package, vs deploying to developer environment. This is one approach we do in a flxbl project

https://docs.flxbl.io/sfp/building-artifacts/controlling-aspects-of-the-build-command/selective-ignoring-of-components-from-being-built

While this approach works relatively well, the con being the duplication involved, a better schematic would be kind of override behavior (merge forceignores) and a command or api to display what is getting ignored