[FEATURE] Merge .fossa.yml and fossa-deps.yml

[thernstig]

Is your feature request related to a problem? Please describe.
Almost all open source tools out there uses one file for all its configurations needs, as its source of truth.

The FOSSA CLI has for some legacy reason opted to use both the file .fossa.yml and fossa-deps.yml for its needs. This is suboptimal as disoverability for developers is harder i.e. to get a full picture of the inputs used by the FOSSA CLI when scanning.

Describe the solution you'd like
Merge them.

Example:

version: 3
server: https://internal.somecompany.com/
project:
  id: some-project
targets:
  only:
    - type: npm
      path: ./

remote-dependencies:
  - name: Node.js
    version: 18.17.1
    url: https://nodejs.org/dist/v18.17.1/node-v18.17.1-linux-x64.tar.gz
    metadata:
      description: Node.js is an open-source, cross-platform JavaScript runtime environment.
      homepage: https://nodejs.org/

This would simplify the setup for everyone and keep one source of truth. This does not need to be a breaking change in case .fossa.yaml is updated to support all top-level keys that exist in fossa-deps.yml. Deprecate fossa-deps.yml and remove support completely in a future release.

[github-actions]

Thank you @thernstig for creating this issue. If this is in regards to a defect, product question or feature request: you should use our support portal at https://support.fossa.com to file a request, as you would receive more immediate support.

[alfrol]

In one of the projects I'm working on we're using pnpm as a package manager. Even though FOSSA supports pnpm as a discovery strategy, the results are incorrect resulting in some of the obvious dev dependencies like typescript to be reported as direct production dependencies. We worked around this issue by dynamically generating a fossa-deps.json file by parsing the output of pnpm ls --prod --json in our build pipeline and pushing the results to FOSSA. Might not be such a common use-case but very convenient. Merging the two files will make it more difficult to dynamically generate the list of dependencies.

[thernstig]

@alfrol the core problem there seems more to stem from the fact that it does not handle pnmp and a separate bug should be submitted for that. I'd personally be hard pressed to take "hacks" into account when designing a solution. Also there is nothing in reality in your script that could not equally well update the contents you do today into a common fossa.json (or .yaml) file.

[alfrol]

the core problem there seems more to stem from the fact that it does not handle pnmp and a separate bug should be submitted for that

That I agree with and I already reached out to folks with that issue.

I'd personally be hard pressed to take "hacks" into account when designing a solution.

Although our workaround is a hack, I wouldn't assume that there are no more use-cases that benefit from the current design. I have a feeling that similar use-cases were exactly why folks at FOSSA decided to split the two files but of course I might be wrong. This is mentioned in the docs here though.

Also there is nothing in reality in your script that could not equally well update the contents you do today into a common fossa.json (or .yaml) file.

I don't know about that. Personally I feel more comfortable generating a separate file rather than modifying a config file and unintentionally breaking something in the configuration. Can it be done? Sure. Should it be done this way? Probably not.

[thernstig]

@alfrol it is very common in most tools (linters) using declarative formats to use one file. Some programming languages go even further supporting one file for all tools (pyproject.toml in Python).

It is very uncommon to add a declarative configuration file for a tool in to separate files like FOSSA does, I'd say it is an outlier.