CAP - Node local workspaces - build issue

[geert-janklaps]

Hi,

I'm creating a CAP application and want to create some re-usable local libraries. (Cloud SDK & re-usable classes)

For this I wanted to make use of the default mechanism provided by NPM, workspaces.

I've setup my package.json to include the workspaces and installed the relevant local modules as dependencies.

So far, so good! Running the application locally is working fine!

Unfortunately when building the project, something strange seems to happen. The workspace folders seem to be added to the MTAR, but only the node_modules folder for that workspace is added and the actual source code seems to be missing.

Example of one of the local modules:

It seems this might be caused by the mbt build tool, as I found an open issue which seems to be similar: MBT build in Project with NPM Workspaces fails to use local dependencies · Issue #1048 · SAP/cloud-m...

The MTA is using a default build configuration for the srv module:

Any tips or tricks to use as a workaround or a solution to this problem?

Best regards,

Geert-Jan

[lochner_louw]

Hey Greet-Jan,

I haven’t tried this myself and I also think it is a MBT issue.

Have you checked what the output directory looks like of ‘cds build’? That usually is the directory that’s gets zipped by the package.

On the other hand why not just import the EDMX or OpenAPI files with ‘cds import’? That will add them as external services into the main cds development.

Regards,

Lochner

[martinfrick]

alperdedeoglu - Can you support? I think you worked on this just recently?

[geert-janklaps]

Hi a126b5c22a3c428aa3310b5d14b6677a,

I actually did the analysis based on the build process step by step. cds build doesn't include the externally referenced folder ("packages" in this case) in the output folder. It's really mbt that adds that folder during the build process it seems. (manually running cds build, doesn't generate that folder).

I'm using Cloud SDK for a few reasons actually:

• Complex (deep insert) scenario's (simulate sales order, create sales order, create purchase order, ...), which to my knowledge are not (yet) possible with external services in CAP?
• Adding resilience, which is supported since v3 of the SDK (How to Make Applications more Resilient? | SAP Cloud SDK)
• Last but not least, I'm using typescript so the fact that Cloud SDK provides a typed API out-of-the-box is just great

Regards,

Geert-Jan

[alperdedeoglu]

Thanks martinfrick
Informed daniel.schlachter about it since he has a better solution than my solution.
He was so kind as usual and he responded already.

[daniel_schlachter · Accepted solution]

Hi Geert-Jan,

please have a look at my blog, where I describe building a plugin for cap, which also uses workspaces:

https://blogs.sap.com/2023/04/30/reusable-components-for-cap-with-cds-plugin/

Currently the deployment should work, if the package name is @capire/... but we are currently working on a generic solution that would be available later (could come with cds 7.1)

For now as a workaround I would either copy the resources manually by adding it as a build step:

build-parameters:
  before-all:
    - builder: custom
      commands:
        - npx -p @sap/cds-dk cds build --production
        - npx copyfiles -f <workspace>/*.* gen/srv/<workspace>/ -a 

...or rename the package.

Of course publishing the package (public or private) and consuming it as a "real" dependency would be the regular way to go.

Thanks

Daniel

[geert-janklaps · Accepted solution]

Hi daniel.schlachter,

Thanks for the tips and insights! I'm definitely going to try both the capire & copy solutions somewhere next week.

In this case it's more a set of central packages to hold some business logic that will be re-used by different different cap-modules in the same project. We're splitting up the project into several micro-services, e.g. one for serving UI services and one for external API access. (So if there is a high load on API's, that doesn't influence services used in UI's, similar to the reasoning behind an mtx-sidecar)

Digging through the npm documentation, this seemed to be the exact intent for the workspace principles. (and avoiding the overhead of maintaining packages in a registry, since these packages are not intended to be used outside the project)

Thanks for the blog! I've used it for the same project a few weeks ago, for a real re-usable cap component which we're now using in different cap projects through our private package registry! Worked like a charm!

Cheers,

Geert-Jan