Generator-jhipster: Broken build with production profile

[pascalgrimaud]

Overview of the issue

Since 2 days, something has changed and the build with production profile is broken: it is impossible to login.

Here the builds:
https://travis-ci.org/hipster-labs/jhipster-travis-build/branches

Motivation for or Use Case

Reproduce the error

In current master:
1) build in production profile
2) launch the application with java -jar target/*.war
3) try to login

I manage to reproduce the same issue in 4.13.0 and 4.12.0 too...
So, I think it comes from a transitive library.

Related issues

N/A

Suggest a Fix

N/A

JHipster Version(s)

master
4.13.0
4.12.0

JHipster Version(s)

[email protected] /home/pgrimaud/tmp/23-default-4.13.0
└── [email protected]  -> /home/pgrimaud/projects/jhipster/generator-jhipster invalid

##### **JHipster configuration, a `.yo-rc.json` file generated in the root folder**

.yo-rc.json file

{
  "generator-jhipster": {
    "promptValues": {
      "packageName": "io.github.pascalgrimaud",
      "nativeLanguage": "en"
    },
    "jhipsterVersion": "4.13.0",
    "baseName": "jhipster",
    "packageName": "io.github.pascalgrimaud",
    "packageFolder": "io/github/pascalgrimaud",
    "serverPort": "8080",
    "authenticationType": "jwt",
    "hibernateCache": "ehcache",
    "clusteredHttpSession": false,
    "websocket": false,
    "databaseType": "sql",
    "devDatabaseType": "h2Disk",
    "prodDatabaseType": "mysql",
    "searchEngine": false,
    "messageBroker": false,
    "serviceDiscoveryType": false,
    "buildTool": "maven",
    "enableSocialSignIn": false,
    "enableSwaggerCodegen": false,
    "jwtSecretKey": "replaced-by-jhipster-info",
    "clientFramework": "angularX",
    "useSass": false,
    "clientPackageManager": "yarn",
    "applicationType": "monolith",
    "testFrameworks": [
      "gatling",
      "protractor"
    ],
    "jhiPrefix": "jhi",
    "enableTranslation": true,
    "nativeLanguage": "en",
    "languages": [
      "en"
    ]
  }
}

JDL for the Entity configuration(s) entityName.json files generated in the .jhipster directory

JDL entity definitions

Environment and Tools

openjdk version "1.8.0_151"
OpenJDK Runtime Environment (build 1.8.0_151-8u151-b12-0ubuntu0.17.10.2-b12)
OpenJDK 64-Bit Server VM (build 25.151-b12, mixed mode)

git version 2.14.1

node: v8.9.3

npm: 5.6.0

bower: 1.8.2

gulp:
[14:09:35] CLI version 3.9.1

yeoman: 2.0.0

yarn: 1.3.2

Docker version 17.09.0-ce, build afdb6d4

docker-compose version 1.16.1, build 6d1ac21

Congratulations, JHipster execution is complete!

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

[jdubois]

I confirm your issue, I can reproduce it locally. Very strange, I'm having a look.

[jdubois]

First time I see a difference between our dev and our prod build, this is crazy. And very hard to debug.

[pascalgrimaud]

I spent 1 hour today to analyze this and didn't find anything sorry.
It worries me because when I checkout an old tag (v4.12.0) and generate a project, I have the issue too.

[jdubois]

The good news is that I know how to correct this (I have it working right now).
But I have no idea what causes the issue!!!!!!!!! This is just me guessing what the issue is and correcting it.
It looks indeed like a transitive dependency, which means our old builds would also be broken. I have no idea what is going on here.
I'll push my "fix" soon.

[jdubois]

OK, this is getting worse. Now that I can login, all forms are broken.
Basically you can't submit a form anymore, that's the real issue.

[jdubois]

It looks like all HTTP requests done through a form are broken - they don't use the correct API URL and just do the request on the server root URL. Maybe this is linked with #6281 ?
The trick to solve this is to remove the "form" tags and force the request using the button, like when it's not inside a form. But I'd rather understand the real issue.

[jdubois]

I confirm this is caused by a transitive NPM dependency.

To reproduce:

• Check out https://github.com/jhipster/jhipster-sample-app-ng2 (that was published 18 days ago)
• Run it in prod mode -> no problem
• Delete the yarn.lock, do a yarn install, and run again in prod -> you can't login anymore

I'm doing some "diff" to find out which dependency causes the issue.
BTW, shouldn't we just commit our own yarn.lock? That would fix that kind of issue in the future (in fact I thought we were already doing that).

[PierreBesson]

I was just going to suggest to commit the yarn.lock as part of generated code but I'm not sure it's possible as this would need to include all possible generated package.json combinations.

[PierreBesson]

Then I guess we could add the "base" yarn.lock file and it should automatically add the missing dependency fixes (which come from non default options) after initial generation.
But this yarn.lock file should be updated manually or with a script which uses : yarn generate-lock-entry.

[jdubois]

@PierreBesson we need to check exactly, because there aren't that many options in the front, maybe we can generate everything

[deepu105]

Generating a yarn lock isn't as easy as it sounds, yarn uses some algorithm to do that, if we want to do it we would have to generate lock file for sass, non sass, i18n and non i18n and we would need to keep it in sync during updating dependencies. Also for npm we would then hv to generate package.lock file. Its a lot of work and technically when a project is generated it should create a lock file using dependencies resolved at that point and IMO current behaviour is correct. And IMO we need to see which rogue dependency is breaking stuff as it would be a semver violation

[jdubois]

The one that is breaking up the build is uglifyjs! Let me do more checks :-)

[jdubois]

Sorry, the real culprit is uglify-es, which "automagically" upgraded from 3.2.2 to 3.3.2!

[jdubois]

@deepu105 should we fix that dependency in package.json and do a new release?

[deepu105]

Just adding the dependency on the package.json wont do anything as the resolution of transitive dependency is still based on what is defined by the libs. For yarn atleast there is an override attribute with which we can fix a transitive dependency, but not for npm

[jdubois]

Oh sorry I thought I was using a real package manager, like we have in Java
:-)

So the only solution we have is to annoy the uglify-es team so they do a
new release?

[jdubois]

Great news, this can be solved by updating the lib that triggers the transitive dependency. PR upcoming!
I'm waiting until tomorrow to check that everything is correct (continuous integration, etc), and will do a release just afterwards!

[pascalgrimaud]

Sorry @jdubois : just tested your fix and I still have the issue :-(

[pascalgrimaud]

I think it's the same issue than this ticket: https://github.com/mishoo/UglifyJS2/issues/2664

[jdubois]

I don't understand @pascalgrimaud as it works on my machine :-)
I'm reopening it and will have a look tomorrow morning.

[jdubois]

Doh! I didn't delete my yarn.lock :-(
Anyway we now know the problem much better, so we can hope for a fix tomorrow

[jdubois]

FYI there is the same problem:

• For Angular: https://github.com/angular/angular/issues/21173
• For Angular CLI: https://github.com/angular/angular-cli/issues/8997

So not fixing transitive dependencies, which I've always said is a huge mistake (see our Policy 4), has broken all Angular builds in the world. Congrats.