Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do not run npm install if generated package json content has not changed #6385

Merged
merged 2 commits into from
Sep 6, 2019

Conversation

denis-anisimov
Copy link
Contributor

@denis-anisimov denis-anisimov commented Sep 3, 2019

Stores hash of the generated package json file in the main package json
(inside node_modules, outside target folder) and updates it every time
when the generated content is changed. TaskUpdatePackages modified
status is changed only if the hash value is changed. It allows do not
run npm install even if the generated package.json file is regenerated.

Fixes #6151


This change is Reviewable

Stores hash of the generated package json file in the main package json
(inside node_modules, outside target folder) and updates it every time
when the generated content is changed. TaskUpdatePackages modified
status is changed only if the hash value is changed. It allows do not
run npm install even if the generated package.json file is regenerated.

Fixes #6151
digest.digest(content.getBytes(StandardCharsets.UTF_8)));
} catch (NoSuchAlgorithmException e) {
// Unrecoverable runime exception, it may not happen
throw new RuntimeException(
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

MAJOR Define and throw a dedicated exception instead of using a generic one. rule

@vaadin-bot
Copy link
Collaborator

SonarQube analysis reported 1 issue

  • MAJOR 1 major

Watch the comments in this conversation to review them.

Copy link
Contributor

@ujoni ujoni left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed 3 of 3 files at r1.
Reviewable status: 4 unresolved discussions, 0 of 1 LGTMs obtained (waiting on @denis-anisimov)


flow-server/src/main/java/com/vaadin/flow/server/frontend/NodeUpdater.java, line 262 at r1 (raw file):

    }

    String writeAppPackageFile(JsonObject packageJson) throws IOException {

While this is an API change, I don't think NodeUpdater is in the public API in any meaningful way. What I do wonder is:
should we also add the return value to writeMainPackageFile, which is a direct mirror to writeAppPackageFile - it would keep the methods consistent with each other.


flow-server/src/test/java/com/vaadin/flow/server/frontend/NodeUpdatePackagesTest.java, line 265 at r1 (raw file):

        packageUpdater.execute();

        System.out.println("xx " + getPackageJson(appPackageJson));

Print should be removed


flow-server/src/test/java/com/vaadin/flow/server/frontend/NodeUpdatePackagesTest.java, line 287 at r1 (raw file):

        packageUpdater.execute();

        System.out.println("xx " + getPackageJson(appPackageJson));

Print should be removed

Copy link
Contributor Author

@denis-anisimov denis-anisimov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dismissed @vaadin-bot from a discussion.
Reviewable status: 3 unresolved discussions, 0 of 1 LGTMs obtained (waiting on @ujoni)


flow-server/src/main/java/com/vaadin/flow/server/frontend/NodeUpdater.java, line 262 at r1 (raw file):
API change: no since the method is package local.

should we also add the return value to writeMainPackageFile

Done.


flow-server/src/test/java/com/vaadin/flow/server/frontend/NodeUpdatePackagesTest.java, line 265 at r1 (raw file):

Previously, ujoni (Joni) wrote…

Print should be removed

Done.


flow-server/src/test/java/com/vaadin/flow/server/frontend/NodeUpdatePackagesTest.java, line 287 at r1 (raw file):

Previously, ujoni (Joni) wrote…

Print should be removed

Done.

Copy link
Contributor

@ujoni ujoni left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:lgtm:

Reviewed 2 of 2 files at r2.
Reviewable status: 1 unresolved discussion, 1 of 1 LGTMs obtained (waiting on @ujoni)

Copy link
Contributor

@ujoni ujoni left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewable status: :shipit: complete! all discussions resolved, 1 of 1 LGTMs obtained

@ujoni ujoni merged commit d887d09 into master Sep 6, 2019
@ujoni ujoni deleted the 6151-package.json-hash branch September 6, 2019 08:08
mehdi-vaadin pushed a commit that referenced this pull request Sep 13, 2019
…ged (#6385)

Stores hash of the generated package json file in the main package json
(inside node_modules, outside target folder) and updates it every time
when the generated content is changed. TaskUpdatePackages modified
status is changed only if the hash value is changed. It allows do not
run npm install even if the generated package.json file is regenerated.

Fixes #6151


(cherry picked from commit d887d09)
mehdi-vaadin pushed a commit that referenced this pull request Sep 13, 2019
…ged (#6385)

Stores hash of the generated package json file in the main package json
(inside node_modules, outside target folder) and updates it every time
when the generated content is changed. TaskUpdatePackages modified
status is changed only if the hash value is changed. It allows do not
run npm install even if the generated package.json file is regenerated.

Fixes #6151


(cherry picked from commit d887d09)
@mehdi-vaadin mehdi-vaadin added this to the 2.0.12 milestone Sep 16, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Do not delete generated package.json on mvn clean
4 participants