@ggerganov @mofosyne

My conclusion is the same. So in the short term, I think updating the index.js in git repo into the new one generated from deps.sh would do.

However In the long run, may be a copy needs to be maintained locally of the js modules, if the reason the deps.sh check was added was to ensure that things dont break if upstream (wrt the js modules) changes. And inturn periodically who ever is maintaining that code, takes a call on pulling in the upstream, after validation.

I recall recent changes in the way we build static assets.

I recall recent changes in the way we build static assets.

Hi @phymbert @ggerganov

Hi phymbert not sure what you meant by static assets, in this case its the external js modules related to preact, which seem to get bundled into index.js file. And looking at the failure, definitely the upstream has changed.

I assume who ever created this flow, added this check so as to be able to cross check, if the upstream has changed wrt what was bundled into index.js. Either way given that the code is picked from the bundled index.js and not from upstream at runtime (ie index.html), I dont think this check should be part of the normal CI flow. Instead this is more a check which should be done by the concerned developer periodically decoupled from the general CI flow, and inturn the bundled in index.js updated once they find that there are no adverse changes in the upstream.

The reason I say above, is because, each time the upstream preact changes, this issue with CI failure will occur, while technically the code in this project is not depending on that upstream in a direct sense.

Rather what I mean is this PR should be merged, and at a later time who ever is currently maintaining the default builtin html+jss code, should potentially look at updating the ci test.