Alizer should be more resilient when detecting ports in a component

[johnmcollier]

I ran Alizer via the command line for a number of Git repositories, and it failed to detect ports in all of them, for varying reasons.

1. For a sample node project: It failed because it can’t handle port declarations like var PORT = process.env.PORT || 8080. It expects something like var PORT = 8080
   • Ideally alizer would be able to handle this scenario too as it seems to be a relatively common convention in nodejs projects
2. For a Go project: It can only handle certain frameworks, and Burr’s repo wasn’t using any specific REST framework.
   • Alizer can handle a number of different Go REST frameworks (e.g. Go-Gin), but it can detect ports that are just using Go's built in net/http web server
3. For Quarkus and Spring Boot projects, there isn’t anywhere in the source code where the port is defined explicitly, and alizer doesn’t make any “assumptions” about default ports it seems (edited)
   • Does alizer benefit from returning the default port (8080) in this scenario? Or should it still return nil?

Update: @thepetk
Target date: 28 Apr 2023

[jduimovich]

For Quarkus the port may be defined in the application.properties src/main/resources/application.properties ie quarkus.http.port=8082
or in yaml
src/main/resources/application.yaml

quarkus:
   http:
     port: 8082

[thepetk]

UPDATE: I've looked into the first issue regarding the nodeJS project. This project is an Express.js project and it uses the express_detector. This is quite different than the rest of the detectors, which are using the package.json in order to recognize any ports. Here we are analyzing the code of the script we find inside the package.json and we are searching for the app.listen.

I've created a PR which adds the required functionality, but I think this should only be added to the express_detector as the rest of the javascript detectors follow a different flow for port recognition.

[thepetk]

UPDATE: For the 2nd case I've created a second PR to add a feature to the go_enricher in order to perform port recognition even if a framework has not been recognized for the given project.

[thepetk]

UPDATE: As for the 3rd case for Quarkus and Spring boot I've been investigating a little bit for Quarkus and Spring (wanted to be sure that they are working properly). I've tested the given repos and:

1. For Quarkus, I can confirm what @jduimovich says. If we set a src/main/resources/application.properties or src/main/resources/application.yaml then alizer is able to recognize the ports.
2. For spring we have the same logic. For example by setting server.port=8080 inside the src/main/resources/application.resources and run alizer we will be able to recognize the port.

Does alizer benefit from returning the default port (8080) in this scenario? Or should it still return nil?

@johnmcollier I agree that this is a good addition. I've created a PR for this issue.