Make updatability of package.json clear

Right now, the way package.json is managed is really unclear for users.

The good part with the current approach makes it possible for users to add new custom dependencies unrelated to their Java code (e.g. sass-loader for webpack). Where it falls apart is any of these cases:

• If the user updates the version of a dependency in their pom.xml, then the corresponding dependency in package.json remains on its old version. This can to some degree be fixed by adding logic that explicitly forces the version in package.json to be in sync with whatever is found from annotations on the classpath. The drawback of that “fix” is that the user will no longer be able to explicitly override to use an older or newer version of the JS module to e.g. work around some specific bug in the current version.
• If the user removes a dependency from their pom.xml, then the corresponding dependency is not removed from package.json. We cannot remove any dependencies from package.json without risking to remove something that the user has explicitly put there independently of what they happen to have on the classpath.

Both problems can trivially be solved by always recreating the file and thus never allowing the user to make any modifications.

If we want to allow the user to modify the dependencies, we should do so in a way that

• doesn’t cause problems to those that haven’t done any customization
• allows a user who wants to modify the file to actually be in control over the file

I see two basic approaches for achieving this. The simple approach is all-or-nothing: the user can choose between giving full control to Flow or prevent Flow from making any changes at all. This could be expressed e.g. as an option in a configuration file or by opting out if package.json contains any other top-level properties than dependencies and devDependencies.

There is also a slightly more complex alternative that would make everything work automatically for users who don’t want to make any own customization, but also make it possible to customize things while still benefitting from automatic resource management for anything referenced by Flow. The idea here would be to have a secondary package.json file that is always rewritten based on dependencies from Java classes. The primary package.json file would then be almost fully in the user’s control, except that it would contain one entry that references the definition managed by Flow.

To summarize: we should either make the file explicitly out-of-bounds, or alternatively make it modifiable in a way that doesn’t cause drawbacks for those who don’t modify it. The current in-between approach is bad for both user categories.

[Legioth]

@pleku That is one part of the problem.

The second part is whether we want to support scenarios where the application developer wants to customize the dependencies. If decide that we don’t want to support that (for now), then we should remove the current ambiguity that might give the developer the impression that it’s actually supported. If we want to support it, then we should make it work in a meaningful way.

[pleku]

Currently we also have an issue with getting “random failure” for a project because the dependencies might be broken and we don’t know it, it depends on what npm install does: https://github.com/vaadin/flow/issues/5320

To my limited understanding it is because

• the lack of a package-lock file
• lack of the versioning information in the annotation ^ as claimed above

The original idea we had was to provide the version in the package.json for the component, but then we opted for the annotation instead. But I guess the version was removed (or not added) because we figured that webpack can figure out a correct version - but this can cause issues as presented ^.

So trying to summarize the problems please correct me if I’m wrong:

• we might have broken frontend dependencies at any point for the starters
• when updating the Vaadin version in pom.xml (where everyone will do it), it is not reflected on package.json and you don’t get the fixes automatically. This is the same for any version bump.