fix: removed old library and added autogenerated one

[alexpargon]

these changes still need work due to missing properties on the backend definition of the api surfaces:

src/components/data/JobSelector.tsx:186:17 - error TS2339: Property 'status' does not exist on type 'FunctionJob'.
  Property 'status' does not exist on type 'ProjectFunctionJob'.

186             job.status = (job.status as unknown as { status: string }).status;
                    ~~~~~~

src/components/data/JobSelector.tsx:290:50 - error TS2339: Property 'uid' does not exist on type 'Function'.
  Property 'uid' does not exist on type 'ProjectFunction'.

290     await updateJobCollections(selectedFunction?.uid as string);

src/components/plots/PlotTools.tsx:23:23 - error TS18047: 'job.inputs' is possibly 'null'.

23         const value = job.inputs[varName];
                         ~~~~~~~~~~

src/components/sampling/LHSSampling.tsx:91:11 - error TS18048: 'localJC.jobIds' is possibly 'undefined'.

91           localJC.jobIds.map(async id => {
             ~~~~~~~~~~~~~~

src/components/setup/FunctionList.tsx:123:46 - error TS2339: Property 'uid' does not exist on type 'ProjectFunction'.

123               uuid: (fun as ProjectFunction).uid,
                                                 ~~~

src/components/setup/FunctionList.tsx:175:55 - error TS18048: 'fun.outputSchema.schemaContent' is possibly 'undefined'.

175     console.log("outputVars registered:", Object.keys(fun.outputSchema.schemaContent.properties));
                                                          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

src/components/setup/FunctionList.tsx:310:34 - error TS2339: Property 'uid' does not exist on type 'Function'.
  Property 'uid' does not exist on type 'ProjectFunction'.

310               {selectedFunction?.uid === params.row.uid ? "Unselect" : "Select"}
                                     ~~~

src/components/setup/FunctionList.tsx:310:53 - error TS2339: Property 'uid' does not exist on type 'Function'.
  Property 'uid' does not exist on type 'ProjectFunction'.

310               {selectedFunction?.uid === params.row.uid ? "Unselect" : "Select"}
                                                        ~~~

src/utils/function_utils_mockups.ts:40:5 - error TS2339: Property 'status' does not exist on type 'SolverFunctionJob'.

40   j.status = "COMPLETED";
       ~~~~~~

they need to be fixed before this PR will work

[Copilot]

Pull Request Overview

This PR replaces an old osparc API client library with an autogenerated one, updating import paths across the codebase from relative imports to the new osparc-api-ts-client package name.

• Updated all import statements from relative paths (../../osparc-api-ts-client) to the npm package name (osparc-api-ts-client)
• Added OpenAPI generator tooling and configuration for automated client generation
• Generated new API client files in the osparc-api-ts-client directory

Reviewed Changes

Copilot reviewed 154 out of 172 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
node/package.json	Added OpenAPI generator dependency and npm script for client generation
node/openapitools.json	Added OpenAPI generator configuration for TypeScript client generation
node/src/osparc-api-ts-client/*	Generated TypeScript API client files (models, APIs, utilities)
node/src/context/*	Updated import paths to use npm package name instead of relative paths
node/src/components/*	Updated import paths to use npm package name instead of relative paths

Files not reviewed (2)

• node/package-lock.json: Language not supported
• node/src/osparc-api-ts-client/package-lock.json: Language not supported

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[wvangeit]

Wrt to the above, this will have to be fixed by using the correct types in the flaskapi/frontend.
E.g.:
ProjectFunction doesnt have an uid, that is only for a RegisteredProjectFunction.
Functionjob doesnt have a status, that is FunctionJobWithStatus

[wvangeit]

and wrt the 'is possibly undefined' errors etc. Yeah, some of these fields are nullable, so you will have to be able to handle that case in your code.

[JavierGOrdonnez]

@alexpargon what is the status of this?

Also, if adding the api-files to gitignore, then please include the generation command in the Makefile or elsewhere - otherwise it will only work in your directory and building will fail for the CI or any other dev.

[alexpargon]

@alexpargon what is the status of this?

Also, if adding the api-files to gitignore, then please include the generation command in the Makefile or elsewhere - otherwise it will only work in your directory and building will fail for the CI or any other dev.

The generation is on the package.json file, just run the "generate-osparc-cli": "openapi-generator-cli generate" command, which will generate the API, there are still some changes pending so this PR has to be worked on yet

[alexpargon]

@JavierGOrdonnez

Now this branch compiles and works, but still requires proper testing, as something can be broken with so many changes.

the openapi-generator-cli command requires JAVA to be installed on the host, thus the reason i did not add it to the makefile yet, as it will require to also install it if run on the compilation process, which might encourage us to just move away of this approach.

i finally added also the JRE installation process on the dockerfile for the Node build process and it compiles as it should, only testing remains

[wvangeit]

Now this branch compiles and works, but still requires proper testing, as something can be broken with so many changes.

Yeah, i have a feeling that you might want to hold this one off until after the release, we don't have much time anymore to fix things.

[JavierGOrdonnez]

Well, I am also changing the backend extensively, including error propagation - and if there are breaking changes in the backend, we will encounter them whether we update the client's reference API or not (NB this is just updating the types for TypeScript to reference, all real interactions happen through Python)

[alexpargon]

in any case this is done, so we can either merge it after testing it or wait for it after release

[JavierGOrdonnez]

I was thinking, maybe we want to apply the same hold-on logic to my branch as well. We could create a "release" branch to which we only merge changes that we consider safe, and focuses mostly on UI/UX features by @alexpargon . We can keep merging the more risky stuff in main, keep merging release into it, and only merge main into release once we are reasonably sure of its stability.

@wvangeit what do you think?

[alexpargon]

I was thinking, maybe we want to apply the same hold-on logic to my branch as well. We could create a "release" branch to which we only merge changes that we consider safe, and focuses mostly on UI/UX features by @alexpargon . We can keep merging the more risky stuff in main, keep merging release into it, and only merge main into release once we are reasonably sure of its stability.

@wvangeit what do you think?

This is normally called a development branch:

[wvangeit]

In general I'm ok with a development branch, or even in favor.
But even that i would just keep off until after the release, especially since this PR triggers quite some changes, and merging fix from the dev branch back into main could become a headache.
I would just keep main for now, and leave this PR for after the release.