Project Structure

We've had a brief discussion in #1073 about the project structure w.r.t to the file hierarchy / naming and go packages.

We kinda agree that with the growing amount of resources and data sources it somewhat gets harder to locate files, especially non-resource / datasource files like helpers and utils.

Another problem is that pretty much all other files start with resource_gitlab_ or data_source_gitlab_ which already uses unnecessary spacing on the screen without providing much value, especially the _gitlab_ part.

A few mitigations to discuss:

Mitigation 1

Put helpers like access_level_helpers.go, environment_scope_helper.go, ... into a separate helper package directly related to GitLab functionality.

Mitigation 2

Testing helpers like helper_test.go into separate package.

Mitigation 3

Put generic helpers like util.go into separate package. These may also be combined with (1) to not have too many packages ....

Mitigation 4

Rename resource / data source and schema go files, e.g. remove the gitlab infix - however, I kinda like that the complete terraform object name is in the filename ... what do others think here?

Mitigation 5

Put provider boilerplate code like provider.go, config.go and main.go into separate package.

---

When we consider to actually implement any of these mitigations I still think it makes sense to weigh to adhere to de-facto best practices (e.g. coming form the scaffolding project) to make it easier for people to contribute.

Originally posted by @PatrickRice-KSC in https://github.com/gitlabhq/terraform-provider-gitlab/pull/1073#discussion_r873079366