ui5-tooling icon indicating copy to clipboard operation
ui5-tooling copied to clipboard

UI5 Tooling modules might use different installations/instances of each other

Open Bomberus opened this issue 4 years ago • 5 comments

Expected Behavior

Middleware should be added to server

Current Behavior

Custom Middleware no longer works with version 1.13.1. Same Configuration works in 1.13.0, no files were changed, just downgraded to this version.

Steps to reproduce the issue

  1. Create custom middleware in ui5.yaml
  2. ui5.yaml
specVersion: '1.1'
metadata:
  name: nw/core/om/adsconfigui
server:
  customMiddleware:
    - name: cdnProxy
      mountPath: /resources
      beforeMiddleware: serveResources
  1. add middleware ui5.yaml
---
specVersion: '1.1'
kind: extension
type: server-middleware
metadata:
  name: cdnProxy
middleware:
  path: ./lib/middleware/cdn.js
  1. middleware js (lib/middleware/cdn.js)
if (!!!process.env.CDN_URL){
  require('dotenv').config()
}
var proxy = require('http-proxy-middleware');

module.exports = function({resources, options}) {
  return proxy('**', { target: process.env.CDN_URL, changeOrigin: true, secure: false, auth: ${process.env.auth} } )
};

Context

  • Node.js Version: v12.14.0
  • yarn Version: 1.21.1
  • OS/Platform: Windows 10 1809

Affected components (if known)

Log Output / Stack Trace

Error Message:
middlewareRepository: Unknown Middleware cdnProxy

Stack Trace:
Error: middlewareRepository: Unknown Middleware cdnProxy
    at Object.getMiddleware (C:\Users\.....\Documents\Projekte\....\node_modules\@ui5\server\lib\middleware\middlewareRepository.js:18:9)
    at MiddlewareManager.addMiddleware (C:\Users\.....\Documents\Projekte\......\node_modules\@ui5\server\lib\middleware\MiddlewareManager.js:37:49)
    at MiddlewareManager.addCustomMiddleware (C:\Users\.....\Documents\Projekte\......\node_modules\@ui5\server\lib\middleware\MiddlewareManager.js:176:15)
    at MiddlewareManager.applyMiddleware (C:\Users\.....\Documents\Projekte\....\....\node_modules\@ui5\server\lib\middleware\MiddlewareManager.js:25:14)
    at async Object.serve (C:\Users\....\Documents\Projekte\.....\node_modules\@ui5\server\lib\server.js:137:3)
    at async Object.serve.handler (C:\Users\.....\Documents\Projekte\....\....\node_modules\@ui5\cli\lib\cli\commands\serve.js:108:33)

Bomberus avatar Jan 28 '20 11:01 Bomberus

Hey @Bomberus, I double checked the changes we released with the v1.13.1 patch. However I couldn't find an indication that it might cause this issue.

Just from looking at the error message, I can only suspect that there might be multiple installations of the @ui5/server package. You may check this with npm list, @ui5/server should only appear in version 1.5.3 and should be "deduped".

Anyways, could you please remove the node_modules directory in your project and execute npm install once again?

RandomByte avatar Jan 28 '20 13:01 RandomByte

Hi @RandomByte, so according to yarn docs, dedupe should automatically happen. Never the less, I removed the node_modules folder and installed everything again.

When exporting the package list (yarn list) I noticed:

├─ @ui5/[email protected]
├─ @ui5/[email protected]
│  ├─ @ui5/server@^1.5.2
│  ├─ @ui5/[email protected]
├─ @ui5/[email protected]
│  ├─ @ui5/project@^1.2.0
│  ├─ @ui5/server@^1.5.3
....

So I guess @ui5/project is importing the older server version?

Bomberus avatar Jan 28 '20 15:01 Bomberus

Never the less, I removed the node_modules folder and installed everything again.

Did this resolve your issue?

So I guess @ui5/project is importing the older server version?

Based on your code snippet, this seems to be the case.

With npm this should be prohibited by the npm-shrinkwrap.json of the UI5 CLI which defines exactly one version of @ui5/server to install which fulfills the range required by @ui5/project.

Apparently Yarn ignores this npm-shrinkwrap.json as per its documentation:

If you are using an npm-shrinkwrap.json file right now, be aware that you may end up with a different set of dependencies. Yarn does not support npm shrinkwrap files as they don’t have enough information in them to power Yarn’s more deterministic algorithm.

But still, since @ui5/cli requires @ui5/[email protected], yarn should be able to dedupe and install 1.5.3 for @ui5/project as well. Apparently it doesn't. Maybe it has good reasons for that?

In case you have a yarn.lock file in your project, maybe check whether it defines two versions for @ui5/server and try to resolve this using yarn upgrade

Bottom line is that this is a bug with the UI5 Tooling. We should be able to work in an environment where multiple versions of our modules are present. Thanks for reporting!

RandomByte avatar Jan 28 '20 16:01 RandomByte

Hi @RandomByte, thanks for your quick help.

Deleting the yarn.lock file and reinstalling the node_modules did the trick.

Bomberus avatar Jan 29 '20 08:01 Bomberus

Hi @RandomByte,

i deleted the yarn.lock file and the node_modules folder. I reinstalled @ui5/cli and now i got installed one version of @ui5/server:

yarn list --pattern @ui5/server
yarn list v1.22.0
warning package.json: No license field
warning ..\package.json: No license field
warning [email protected]: No license field
└─ @ui5/[email protected]
Done in 0.33s.

However the problem persists: Unknown Middleware...

When debugging this, i could not find any code adding my custom middleware to the middlewares object of the middlewareRepository, leading to this error. How could this ever work like this? Shouldn't be called middlewareRepository.addMiddleware at first when adding a custom middleware?

UPDATE: I cloned the openui5-sample-app and started the ui5 server there to get the call stack. For some reason the search results in VSCode didn't show me the call of addMiddleware in the projectPreprocessor. I realized that i had a task in a dependent project with the same name as my middleware, causing the extension not to be registered again. Now it's running ;-)

johannesrue avatar Feb 17 '20 10:02 johannesrue

This issue should be resolved in the v3 releases. We changed the critical APIs to rely on dependency injection, rather than requiring the modules independently (which lead to issues like this).

RandomByte avatar Jun 09 '23 09:06 RandomByte