Generator-jhipster: Application version is "UNKNOWN" when running "npm start"

Created on 8 Aug 2019  Â·  12Comments  Â·  Source: jhipster/generator-jhipster

Overview of the issue

when running ./mvnw -Pprod and then npm start the version is set to UNKNOWN.

Motivation for or Use Case

I should be able to see the app's version. This was working before 6.2.0

Reproduce the error

run ./mvnw -Pprod and access localhost:8080. App's version is present. Then run npm start, version is UNKNOWN for both localhost:8080 and localhost:9000

Related issues

_Unknown_

Suggest a Fix

I'm not sure about how to fix it.

JHipster Version(s)

6.2.0

JHipster configuration
JHipster Version(s)
[email protected] /home/alejandro/IdeaProjects/facturapp
├── [email protected] 
└─┬ [email protected]
  └── [email protected]  deduped

##### **JHipster configuration, a `.yo-rc.json` file generated in the root folder**
.yo-rc.json file
{
    "generator-jhipster": {
        "promptValues": {
            "packageName": "com.almasoft.facturapp",
            "nativeLanguage": "es"
        },
        "jhipsterVersion": "6.2.0",
        "applicationType": "monolith",
        "baseName": "FacturApp",
        "packageName": "com.almasoft.facturapp",
        "packageFolder": "com/almasoft/facturapp",
        "serverPort": "8080",
        "authenticationType": "session",
        "cacheProvider": "ehcache",
        "enableHibernateCache": true,
        "websocket": "spring-websocket",
        "databaseType": "sql",
        "devDatabaseType": "mariadb",
        "prodDatabaseType": "mariadb",
        "searchEngine": false,
        "messageBroker": false,
        "serviceDiscoveryType": false,
        "buildTool": "maven",
        "enableSwaggerCodegen": false,
        "rememberMeKey": "YourJWTSecretKeyWasReplacedByThisMeaninglessTextByTheJHipsterInfoCommandForObviousSecurityReasons",
        "clientFramework": "angularX",
        "clientTheme": "spacelab",
        "clientThemeVariant": "light",
        "useSass": true,
        "clientPackageManager": "npm",
        "testFrameworks": [],
        "jhiPrefix": "jhi",
        "entitySuffix": "",
        "dtoSuffix": "DTO",
        "otherModules": [],
        "enableTranslation": true,
        "nativeLanguage": "es",
        "languages": ["es"],
        "blueprints": []
    }
}

Environment and Tools

openjdk version "11.0.4" 2019-07-16
OpenJDK Runtime Environment (build 11.0.4+11-post-Ubuntu-1ubuntu218.04.3)
OpenJDK 64-Bit Server VM (build 11.0.4+11-post-Ubuntu-1ubuntu218.04.3, mixed mode, sharing)

git version 2.17.1

node: v10.16.0

npm: 6.10.2

yeoman: 3.1.0

Docker version 19.03.1, build 74b1e89

docker-compose version 1.24.1, build 4667896b

Browsers and Operating System

Ubuntu Bionic.
Brave Browser

  • [x] Checking this box is mandatory (this is just to show you read everything)

Love JHipster? Please consider supporting our collective:
👉 https://opencollective.com/generator-jhipster/donate

area front

Most helpful comment

@jack-kerouac Totally agree. The parsing code before was much worse to understand and maintain. So if everyone is okay with using DEV when doing npm start I can do that and update the documentation accordingly.

All 12 comments

Version extract logic changed in #9986 which states:

The downside is that if only npm start is run,
instead of the version, UNKNOWN is shown.

But if I tested then experienced also behaviour described in this issue: if running npm start then version is UNKNOWN (both for localhost:9000 and localhost:8080), even if mvnw, mvnw -Pprod, gradlew or gradlew -Pprod is running.

One possible fix is:

VERSION: `'${process.env.hasOwnProperty('APP_VERSION') ? process.env.APP_VERSION : 'UNKNOWN'}'`

to

VERSION: `'${process.env.hasOwnProperty('APP_VERSION') ? process.env.APP_VERSION : utils.parseVersion()}'`

My suggested fix in previous comment is not correct. If using version from Git then parsing breaks when running npm start.

One possible solution is to revert #9986 and if modifying build.gradle to use version from git then modify also webpack files to get also version from git, for example using https://www.npmjs.com/package/git-revision-webpack-plugin

run ./mvnw -Pprod and access localhost:8080. App's version is present. Then run npm start, version is UNKNOWN for both localhost:8080 and localhost:9000

I believe it's due to both npm start and mvnw builds producing artifacts in the same directory target/classes/static/ and the one generated by npm start doesn't contain the version.

cc @jack-kerouac, as you're the one who did the PR.
Can you help us on this ticket plz ?

Another possible solution: Gradle and Maven will write version to package.json and webpack reads version from package.json as implemented in #9994

Or just use '${packageJson.version}' instead of UNKNOWN.

Thanks for mentioning me. Indeed, my change in https://github.com/jhipster/generator-jhipster/pull/9986 caused this behavior.

In this PR, I was aware of this downside, but decided to still solve it in this way:

I think the advantages (allowing dynamic version in Gradle, removing parsing code) outweigh this downside.

The point is that once the application is built and run in production mode, the correct version is shown. But I can see that this fact is not obvious to someone getting started with JHipster.

One possible change is to show vDEV instead of vUNKOWN. Another potential change is to mention in the documentation that when running npm start for development, the version is not shown. Setting the APP_VERSION environment variable when running npm start (APP_VERSION=42 npm start) again shows the version.

Easier to maintain is a change to the documentation. Less code in the project. I thus suggest to show vDEV (or vDEVELOPMENT) instead of vUNKNOWN and mention this in the documentation.

@jack-kerouac Totally agree. The parsing code before was much worse to understand and maintain. So if everyone is okay with using DEV when doing npm start I can do that and update the documentation accordingly.

Agree too, let's keep this simple. In DEV, we don't care about the version, so I'm ok to have DEV, rather than UNKNOWN

yeah, it makes sense

Was this page helpful?
0 / 5 - 0 ratings

Related issues

DanielFran picture DanielFran  Â·  3Comments

kaidohallik picture kaidohallik  Â·  3Comments

chegola picture chegola  Â·  4Comments

tomj0101 picture tomj0101  Â·  3Comments

SudharakaP picture SudharakaP  Â·  3Comments