fix: fixed versions in postgres deployer package.json

[nils]

We were surprised by fields like CreatedByUserDescription, LastChangedByUserDescription, InProcessByUserDescription in the DraftAdministrativeData in our deployed DB.

The cause was that without fixed versions, the deployer took the most recent @sap/cds (from the "^9" range, which is 9.3.x right now). 9.3 added the fields mentioned above (see Capire changelog), while we still are (and want to be) on 9.2.x.

This is one potential solution (use the same versions as we had them during build), but I'm open for different ones!

[johannes-vogel]

@patricebender @swaldmann Isn't the idea to have a package.json in the db directory which is taken over during build? This already gives control to app developers which versions are used.

Is the generated deployer app only part of the generated artifacts or is it version controlled? If version controlled, I am against pinning the versions.

[patricebender]

Is the generated deployer app only part of the generated artifacts or is it version controlled? If version controlled, I am against pinning the versions.

the package.json of the deployer app will be located in gen/pg/ which is generally not under version control - I think.

Isn't the idea to have a package.json in the db directory which is taken over during build? This already gives control to app developers which versions are used.

Yes my assumption was that it is supposed to be that way. However, we had issues in the past because certain build relevant informations were not propagated to the deployer package.json (see #1018 & #1206)

That being said I think it makes sense to use the same cds version in the deployer app as in the applications main package.json. @swaldmann @daogrady do you agree?

[daogrady]

@daogrady do you agree?

Using the same versions definitely sounds extremely reasonable. But I am not familiar with the local db/package.json Johannes mentioned and I do not know what led to its introduction.

[nils]

Isn't the idea to have a package.json in the db directory which is taken over during build? This already gives control to app developers which versions are used.

If that's the idea, please enforce or encourage it somehow. I only found this option during debugging, and from the code it looks like it is only an option. If it is not there, a simple package.json will be generated during build, and that is sufficient for us once this patch is in (and it would be sufficient for many other users, I assume).

[swaldmann]

Isn't the idea to have a package.json in the db directory which is taken over during build? This already gives control to app developers which versions are used.

Yes, it's possible to override the build-generated package.json this way. However, this is ideally not necessary, therefore I'd be careful encouraging or promoting it.

That being said I think it makes sense to use the same cds version in the deployer app as in the applications main package.json. @swaldmann @daogrady do you agree?

I like the idea to let the deployer app inherit the main dependencies if not specified otherwise 👍 Will probably lead to fewer surprises than the current approach (which is also used in the HANA build).