loadable not working in SSR with webpack module federation -

🐛 Bug Report
loadable-components: failed to synchronously load component, which expected to be available { fileName: './src/shared/dedicated/index.js',
chunkName: 'Dedicated',
error: 'Cannot read property 'call' of undefined' }
(node:7562) UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'call' of undefined
at webpack_require (/Users/ajay/Desktop/WebStrom/MicroFrontend/Edge/dist/server/main.js:394:42)
at Module../src/shared/components/Footer/index.js (/Users/ajay/Desktop/WebStrom/MicroFrontend/Edge/dist/server/Dedicated.server.js:21:71)
at webpack_require (/Users/ajay/Desktop/WebStrom/MicroFrontend/Edge/dist/server/main.js:394:42)
at Module../src/shared/dedicated/index.js (/Users/ajay/Desktop/WebStrom/MicroFrontend/Edge/dist/server/Dedicated.server.js:60:76)
at webpack_require (/Users/ajay/Desktop/WebStrom/MicroFrontend/Edge/dist/server/main.js:394:42)
at Object.requireSync (/Users/ajay/Desktop/WebStrom/MicroFrontend/Edge/dist/server/src_server_render_js.server.js:225:14)
at InnerLoadable.loadSync (/Users/ajay/Desktop/WebStrom/MicroFrontend/Edge/dist/server/vendors-node_modules_loadable_server_lib_index_js-node_modules_express_index_js-node_modules_-ee7ccd.js:420:35)
at new InnerLoadable (/Users/ajay/Desktop/WebStrom/MicroFrontend/Edge/dist/server/vendors-node_modules_loadable_server_lib_index_js-node_modules_express_index_js-node_modules_-ee7ccd.js:315:17)
at processChild (/Users/ajay/Desktop/WebStrom/MicroFrontend/Edge/dist/server/vendors-node_modules_loadable_server_lib_index_js-node_modules_express_index_js-node_modules_-ee7ccd.js:56603:14)
at resolve (/Users/ajay/Desktop/WebStrom/MicroFrontend/Edge/dist/server/vendors-node_modules_loadable_server_lib_index_js-node_modules_express_index_js-node_modules_-ee7ccd.js:56568:5)
(node:7562) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:7562) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
To Reproduce
routes.js -
import React from 'react'
import loadable from '@loadable/component'
// import Home from './home'
// import Dedicated from './dedicated'
const Home = loadable(() => import(/* webpackChunkName: "Home" / './home'))
const Dedicated = loadable( () => import(/ webpackChunkName: "Dedicated" */ './dedicated'))
const homeRoute = (path) => ({
path,
exact: true,
component: Home
})
const dedicatedRoute = (path) => ({
path,
exact: true,
component: Dedicated
})
export default () => [
homeRoute('/'),
dedicatedRoute('/:player(messi)')
]
Expected behavior
A clear and concise description of what you expected to happen.
Link to repl or repo (highly encouraged)
https://github.com/ajayjaggi/MicroForntEnd-Basic-Structure
Issues without a reproduction link are likely to stall.

Hi. i saw this PR  https://github.com/gregberge/loadable-components/pull/638/files and used these fixes to run loadable in my local along with webpack 5. But further in SSR wrapping components with loadable breaks the flow...Error is published above.
Also i have mentioned my repo link..

Hello @ajayjaggi,
did you try to use correct patch for chunkExtractor.js?
this
https://github.com/gregberge/loadable-components/pull/638/files#diff-ae8b2f8a1736c52b65efbc3c341977cb11ce566027e0befaf874569fe969dcadR208
instead of
https://github.com/ajayjaggi/MicroForntEnd-Basic-Structure/blob/master/Edge/node_modules/%40loadable/server/lib/ChunkExtractor.js#L208
example
return {
-     cleanFilename,
+     filename: resolvedFilename,
...

Thanks for this.I had used the wrong key.
Have corrected this but still getting the same error.

Did you use webpack LoadablePlugin in your webpack config?

yes for both the websites ie Edge and Demand i have used LoadablePlugin in the webpack config for client side.
demand website - https://github.com/ajayjaggi/MicroForntEnd-BasicStructure/blob/master/Demand/config/webpack/client.js
edge website - https://github.com/ajayjaggi/MicroForntEnd-Basic-Structure/blob/master/Edge/config/webpack/client.js

https://github.com/ajayjaggi/MicroForntEnd-Basic-Structure - this is the PR for project

It may take a while before it will start working properly, but 🤞

Hi @StephaneRob / @theKashey ,can we connect over a call to discuss the issue ? We can try to find the solution together.

@ScriptedAlchemy is the boss in MF lands. We all need his help, not my help.
PS: https://github.com/gregberge/loadable-components/issues/635 sounds to be related. We need unique callbacks for every remote. Or we don't?

Each host has a name. Webpack usually appends a name to the remote containers. So they get their own name.
Webpack accesses the runtime via window.app1.get.
App1 is the name you call it in the config.
I'm not sure if jsonp matters because they all get namespaced. It would have to be tested but I use loadable and do not have problems. However I'm using MF not standard entry-point runtimes which execute differently.

Quoting from a comment I left on recently merged PR:
If you have the remotes on the page immediately. Like hardcoded. All remote code should transport down in a single RTT.
If you want to SSR the chunks a remote requires:
loadable needs a new way to map names of remotes to federated chunk maps.
I need to extend the MF api so remotes will export their chunk maps so loadable can extract them during render.
Whenever you use loadable. Babel basically transforms the import into a object with a normal require statement and the module / chunk id. Then it's executed the HOC pushes these IDs into a scope that the server can access after the react render.
The only Id it will have is ./someExposedModule - and we would need to go over the remotes stats and find what the browser side script is for that module.
Same problem exists in next js. The loadable method straight crashes.
No existing code split tool is capable of MF chunk coronations. I work around hydration issues with top level awaits. Which work on both client and server.
You could also use partial hydration and simply hydrate markup when visible.
I don't foresee this being hard to accomplish. Especially since I can extend MF apis at will.
We could even change the getter on the remote so whenever a server gets code from the remote, it's container will report what request was asked for from the remote. It actually could be done without and need for Babel at all, or even loadable HOC. The only part we would need to adapt is ChunkExtractor to read from the second scope the remote containers are accessing directly.
This mechanism would work exactly like react-universal does. Push right into a map, but we will be doing this inside the webpack runtime directly.
MF should not be a complex problem to render correctly on. You don't need to use loadable as a wrapper 👆 we only need to flush chunks into it from webpack runtime.

@theKashey how can I import and push extra chunk names into your context.
How can we have loadable read the remote containers chunks. I can have webpack infer this from the plugin.
What we could do is provide a loadableFederationPlugin which passes the object to MF but we can read the info.
Then we would have the paths to all remotes and can require the chunk stats upfront.
I could write to a map you expose directly in webpack. As the runtime attaches, it sends context to the host. The "hard" part on the webpack side is emitting the stats and reducing it down to simple maps.
If I'm able to push chunk maps and the module as it's required at runtime. This would make it much simpler. Then I wouldn't need to provide stats upfront but could push them into loadable as the remote attaches on its own.

Okay, I'm on my iPad to cant really code much. Here's what the startup code will look like. (Check module federation examples/startup-code) to see it configured in webpack.
This entrypoint would be part of webpack-imported, and its added to webpack with something like SingleEntryPlugin or EntryPlugin (or mutation of options, like u do in next)
We can get app1 from webpack and use template strings, or we can compose variables via definePlugin, like you do to env vars.
Global.chunkMap = Map() // or whatever
const container = __webpack_require__('webpack/container/entry/app1');
// app1 could be process.env.CURRENT_HOST or something we can inject during build.
Module.exports = {
  get(request) {Map.add(request); return container.get(request)}
  init() {return container.init(arguments)}
  ClientChunks: non_webpack_require('../clientStats.json') // or some injection to inline this after the fact.
}

We can also use normal require and stuff in here, its just a entrypoint.
As i use federated import(scope/request), RemoteModule will perform global.[scope].get(request)
Since we own the getter, its going to push into a global map. We can then read config from MF plugin to get paths to remote container if we need.
ImportedFederatedPlugin({
Name:app1
Remotes: {otherRemote: path.resolve(pathToRemote)}
})
Now you've got the options passed to MF. So we can infer name, and know how to find the container to get the exported client chunks off it.
You can also use, in the server. So chunkExtractor would go:
remoteChunks = webpack_require(require.resolve(remote)).ClientChunks
Alternatively, we could attach to scope during initialization
{init()=>{Object.assign(global.chunkMaps,ClientChunks)}}

Inside loadable, you'd pretty much want to prevent the typical babel transform. Instead we use webpack directly. We can use require if needed for server transform, then webpack will hoist to app boot time, i think.
Lastly, we could use the existing HOC to push ones actually rendered, depending on if the require function pull the chunks right away. Ideally if we can preloadAll or something it might be better.
There's likely some details to work out but this will work.

hi @ScriptedAlchemy, i was very curious about finding the solution to the problem. If we could talk and you could guide me through, i would be very happy to contribute.

There's other issues that block webpack support besides this :/
But I'll push a branch somewhere soon that you can look at

Hi @ScriptedAlchemy , If you could share the branch it would be great help

I'm building most of this capability into the module federation dashboard.
I'll backport so capabilities to standalone

@theKashey Can we re-open this guy as it's a blocker for users of this package from updating to Webpack 5? Also is there any idea of timing or any assistance we "the community" can help with? CC. @ScriptedAlchemy

@theKashey Can we re-open this guy as it's a blocker for users of this package from updating to Webpack 5? Also is there any idea of timing or any assistance we "the community" can help with? CC. @ScriptedAlchemy

webpack 5 support was already PR-ed - #676, I am waiting for a little free time to get it merged.

webpack 5 support was already PR-ed - #676, I am waiting for a little free time to get it merged.

Amazing, I should have poked around the branches a bit more, I didn't see it linked here 🤷. Thanks again and thank you for all the fantastic work thats gone into this project!!

Amazing, I should have poked around the branches a bit more, I didn't see it linked here 🤷. Thanks again and thank you for all the fantastic work thats gone into this project!!

webpack 5 support was already PR-ed - #676, I am waiting for a little free time to get it merged.

Any progress?

webpack 5 support was already PR-ed - #676, I am waiting for a little free time to get it merged.

Any progress?

Any progress on this? Seems to break razzle builds (hash mismatch on production build)

Watching this issue as well.
I also created a reproduction repo. README has instructions on how to run locally.
https://github.com/suhanw/wp5-modfed-ssr-loadable
A very simple setup where remote exposes TopNav component, and host consumes TopNav.
https://github.com/suhanw/wp5-modfed-ssr-loadable/blob/main/host/client/components/App/index.js
const TopNav = loadable(() => import('remote/top-nav'), { ssr: true });
The line above throws the following error:
loadable-components: failed to synchronously load component, which expected to be available {
  fileName: 'webpack/container/remote/remote/top-nav',
  chunkName: 'remote-top-nav',
  error: '__webpack_modules__[moduleId] is not a function'
}
(node:62803) UnhandledPromiseRejectionWarning: TypeError: __webpack_modules__[moduleId] is not a function
    at __webpack_require__ (/Users/suhanwijaya/Desktop/temp/wp5-modfed-ssr-loadable/host/build/server/bundle.js:249:41)
    at Object.requireSync (/Users/suhanwijaya/Desktop/temp/wp5-modfed-ssr-loadable/host/build/server/server_renderer_js.bundle.js:60:14)
    at InnerLoadable.loadSync (/Users/suhanwijaya/Desktop/temp/wp5-modfed-ssr-loadable/host/node_modules/@loadable/component/dist/loadable.cjs.js:278:35)
    at new InnerLoadable (/Users/suhanwijaya/Desktop/temp/wp5-modfed-ssr-loadable/host/node_modules/@loadable/component/dist/loadable.cjs.js:173:17)
    at processChild (/Users/suhanwijaya/Desktop/temp/wp5-modfed-ssr-loadable/host/node_modules/react-dom/cjs/react-dom-server.node.development.js:3305:14)
    at resolve (/Users/suhanwijaya/Desktop/temp/wp5-modfed-ssr-loadable/host/node_modules/react-dom/cjs/react-dom-server.node.development.js:3270:5)
    at ReactDOMServerRenderer.render (/Users/suhanwijaya/Desktop/temp/wp5-modfed-ssr-loadable/host/node_modules/react-dom/cjs/react-dom-server.node.development.js:3753:22)
    at ReactDOMServerRenderer.read (/Users/suhanwijaya/Desktop/temp/wp5-modfed-ssr-loadable/host/node_modules/react-dom/cjs/react-dom-server.node.development.js:3690:29)
    at Object.renderToString (/Users/suhanwijaya/Desktop/temp/wp5-modfed-ssr-loadable/host/node_modules/react-dom/cjs/react-dom-server.node.development.js:4298:27)
    at _callee$ (/Users/suhanwijaya/Desktop/temp/wp5-modfed-ssr-loadable/host/build/server/server_renderer_js.bundle.js:134:76)

import TopNav from 'remote/top-nav';
This line above appears to work, but extractor.getStyleTags() returns empty string (this seems related to https://github.com/gregberge/loadable-components/issues/706)
@ajayjaggi curious if you found a workaround?

Any progress?
I get the same error
loadable-components: failed to synchronously load component, which expected to be available {
  fileName: './src/components/Mfa_1_app.tsx',
  chunkName: 'components-Mfa_1_app',
  error: '__webpack_modules__[moduleId] is not a function'
}
(node:29690) UnhandledPromiseRejectionWarning: TypeError: __webpack_modules__[moduleId] is not a function
    at __webpack_require__ (/media/gitprodenv/Elements6/Coding/mfa/packages/container/dist-backend/webpack:/@microfrontend/container/webpack/bootstrap:19:1)
    at Object../src/components/Mfa_1_app.tsx (/media/gitprodenv/Elements6/Coding/mfa/packages/container/dist-backend/dev-server-bundle.js:3086:73)
....

Same failed to synchronously load component, which expected to be available
Any updates?

We have built a solve for this, however we need some library updates to be performed to pair our technology with this library

Let's talk about this 🤙

Hello everyone,
I am facing the following issue while loading the web page:
loadable-components: failed to synchronously load component, which expected to be available

I also get errors like this:

react-dom.js:141 TypeError: Cannot read property 'call' of undefined
at a (app.c859347b3447f4265e89.js:2)
at Module.5470 (chunk.Bill.c859347b3447f4265e89.js:1)
at a (app.c859347b3447f4265e89.js:2)
at Object.requireSync (app.c859347b3447f4265e89.js:2)
at n.i.loadSync (app.c859347b3447f4265e89.js:2)
at new n (app.c859347b3447f4265e89.js:2)
at fh (react-dom.js:81)
at Ch (react-dom.js:114)
at Pj (react-dom.js:233)
at di (react-dom.js:168)

Could someone help me with this issue, please?

any updates. please?

@ScriptedAlchemy is the solve you mention the same as described in your Next.js/SSR article? In which case is it tied to Next.js use?

In order to solve this issue on the browser side we need to overcome two problems:
1 - We don't have the chunks that are needed for rendering the components;
2 - loadable-components trying to get the mf chunks by using the following id - webpack/container/remote// while the remote uses different id;
In order to solve these problems, I created two plugins -  "webpack-federation-stats-plugin" and "webpack-federation-module-id-plugin"
webpack-federation-stats-plugin - creates a JSON file that contains all the required chunks of the exposed modules
webpack-federation-module-id-plugin - changes the module id of the exposed modules, so the id will be in the following form: webpack/container/remote/appName/moduleName
Without the plugin:
(self["LOADABLE_LOADED_CHUNKS"] = self["LOADABLE_LOADED_CHUNKS"] || []).push([["src_Button_js"],{
"src/Button": ((__unused_webpack_module, webpack_exports, webpack_require) => {...}
}
With the plugin:
(self["LOADABLE_LOADED_CHUNKS"] = self["LOADABLE_LOADED_CHUNKS"] || []).push([["src_Button_js"],{
"webpack/container/remote/MyAppName/Button": ((__unused_webpack_module, webpack_exports, webpack_require) => {...}
}
After adding these plugins to the remote you need to get the "federation-stats.json" in the host and inject the required chunks into the Html (you should check which components were rendered and send only the relevant chunks).
You can get the rendered components in that way:
const getLoadableRequiredComponents = (extractor) => {
const loadableElement = extractor.getScriptElements().find((el) => el.key === "__LOADABLE_REQUIRED_CHUNKS___ext")
const {namedChunks} = JSON.parse(loadableElement.props.dangerouslySetInnerHTML.__html)
return namedChunks
}

The mf components names are in the following form appName-componentName

@DanielAmenou do you have a working example for those plugins?

[ ] @theKashey to work with @ScriptedAlchemy and @DanielAmenou to create documentation around MF and code-splitting anyone can follow

@nescalante I'm working on it, I'll share it soon.

ר3ק4ר4ק33רר5554ר554רק554445

has been solved as referenced in the PR to MF-examples. Probably could have tighter integration with the core library, but not a showstopper

It can be started from the documentation side.
I am looking forward to refactor ChunkExtractor a little to make webpack-plugin and getAnyScriptTags interchangeable which will easy integration with MF, or any other technology if needed.

Given the above (using "webpack-federation-stats-plugin" and "webpack-federation-module-id-plugin") - is it appropriate to post issues with SSR/loadable/module-federation here?

Wonder how this would work with react18. May not even need loadble-components when react supports it properly with streaming.

I've long ago solved chunk flushing for code split components. All you need to do is merge the stats json chunk that loadable emits, either as env variable or a api call to static asset before flushing chunks.
React 18 supports streaming so this won't be a problem however you'd still want to flush out the JS upfront to avoid round trips when webpack kicks in.
I do already have react 18 level support for federated SSR, async components, and component level data fetching (had it for about 7 months) - however my pattern depends on discovering side effects during render so I'm not suspending leaf nodes server side. Just traverse the app tree before renderToString and flush out and component level data or federated imports, then store it on react context so when renderToString is called, I've already promise.all'd and have the resolved promises available synchronously.
Traversing the app tree added about 80ms of overhead to my lambdas, a small price to pay for production sites that are cached 90% of the time anyways lol

With React 18 it is possible to do SSR and later hydration without any other library involved in the process, however:

unless you use "inlining" CSS-in-JS or critical style extraction you need something like Loadable to add used styles in the page header.
you might suffer from render-as-you-fetch, aka waterfall-ish script loading. You will need an extra tool to discover used scripts and flush them from SSR or the outcome can be completely unbearable. This is greatly dependent on the application and especially application size.
@ScriptedAlchemy - it would be nice to have some stats.json compatible plugin to produce a "federated medium" other libraries can use. In the case of loadable there loadable/webpack-plugin is more than replaceable with any other "source". Would it be enough, and changes to which other systems might be required (like https://github.com/gregberge/loadable-components/pull/7010?

We released a webpack federated stats plugin many months ago to solve chunk flushing at server time. It works just fine under my use cases, haha, but I have custom everything. Someone could send a Pr and adjust the stats emitted, or an adapter output could be added for loadable to perform lookups similar to how it does today

Ok, I know what you are talking about. I'll take a deeper look

Hey guys, the PR is still in open state! Any updates here? @ScriptedAlchemy  @theKashey

I’m about to release this flush chunks capability for next.js federated SSR plugin.
Here’s how i did it.
During server build, I attach a small chunk map to module federation apis. So when i call the remote container on a server, it as an object of mappings.
I read the loadable context which has a mapping of all dynamic imports, the federated ones will have an empty array since theres no known files. I loop over the original manifest and attach any matching imports to the remote modules onto that object. Now when they are flushed out, loadable also flush’s out the federated modules alongside it. To deal with asset prefix, i created something similar to document.currentScript for node - this lets me convert relative paths to absolute urls inside the consumer on the fly.

Okay so i juuuust finished implementing chunk flushing and federated SSR + nested remote import chunk flushing.
This is a copy/paste of what I've got so far. Note: this required a hack to take over react loadable since next.js provides no useful ways to break into the chunk flushing mechanism. However, it should give you some idea on how to flush chunks out for federated modules.

const extractChunkCorrelation = (remoteContainer, lookup, request) => {
  if (
    remoteContainer &&
    remoteContainer.chunkMap &&
    remoteContainer.chunkMap.federatedModules
  ) {
    const path = remoteContainer.path.split("@")[1];
    const [baseurl] = path.split("static/ssr");
    remoteContainer.chunkMap.federatedModules.map((federatedRemote) => {
      federatedRemote.exposes[request].forEach((remoteChunks) => {
        remoteChunks.chunks.map((chunk) => {
          if (!lookup.files.includes(new URL(chunk, baseurl).href)) {
            lookup.files.push(new URL(chunk, baseurl).href);
          }
        });
      });
    });
  } else {
    console.warn(
      "Module Federation:",
      "no federated modules in chunk map OR experiments.flushChunks is disabled"
    );
  }
};
const requireMethod =
  typeof __non_webpack_require__ !== "undefined"
    ? __non_webpack_require__
    : require;
const requestPath = path.join(
  process.cwd(),
  ".next",
  "server/pages",
  "../../react-loadable-manifest.json"
);
let remotes = {};
const loadableManifest = requireMethod(requestPath);
requireMethod.cache[requestPath].exports = new Proxy(loadableManifest, {
  get(target, prop, receiver) {
    if (!target[prop]) {
      let remoteImport = prop.split("->")[1]

      if (remoteImport) {
        remoteImport = remoteImport.trim();
        const [remote, module] = remoteImport.split("/");

        if (!remotes[remote]) {
          Object.assign(remotes,generateDynamicRemoteScript(global.loadedRemotes[remote]))
        }

        const dynamicLoadableManifestItem = {
          id: prop,
          files: [],
        };
        // TODO: figure out who is requesting module
        let remoteModuleContainerId
          Object.values(global.loadedRemotes).find((remote)=> {
          if(remote.chunkMap && remote.chunkMap.federatedModules[0] && remote.chunkMap.federatedModules[0].remoteModules) {
            if(remote.chunkMap.federatedModules[0].remoteModules[remoteImport]) {
              remoteModuleContainerId = remote.chunkMap.federatedModules[0].remoteModules[remoteImport]
              return true
            }
          }
        })
        if(remoteModuleContainerId) {
          dynamicLoadableManifestItem.id = remoteModuleContainerId
        }
        extractChunkCorrelation(
          global.loadedRemotes[remote],
          dynamicLoadableManifestItem,
          `./${module}`
        );
        return dynamicLoadableManifestItem;
      }
    }
    return target[prop];
  },
});

const flushChunks = async (remoteEnvVar = process.env.REMOTES) => {
  remotes = {}
  const remoteKeys = Object.keys(remoteEnvVar);
  const preload = [];

  try {
    for (const key in loadableManifest) {
      const [where, what] = key.split("->");
      const request = what.trim();
      const foundFederatedImport = remoteKeys.find((remoteKey) => {
        return request.startsWith(`${remoteKey}/`);
      });
      if (foundFederatedImport) {
        const remotePreload = remoteEnvVar[foundFederatedImport]().then(
          (remoteContainer) => {
            Object.assign(remotes,generateDynamicRemoteScript(remoteContainer))

            const inferRequest = what.split(`${foundFederatedImport}/`)[1];
            const request = `./${inferRequest}`;
            extractChunkCorrelation(
              remoteContainer,
              loadableManifest[key],
              request
            );
          }
        );
        preload.push(remotePreload);
      }
    }
    await Promise.all(preload);
    return remotes
  } catch (e) {
    console.error("Module Federation: Could not flush chunks", e);
  }
  return [];
};

🙄 not sure this solution is portable. Let's tackle it step by step.
There are good (and small) examples of federation, so let's eat bear in parts.
The only operation loadable need - is to map "filename" into remote script. Currently it's made via naming all chunks manually and at the build time, what is definitely not gonna work with remotes.
So let's break everything into pieces and eat bear in parts.

@theKashey lets find some time to dig into an example and work on a solution. From my end I feel this is simple to resolve with the help of strong dev like yourself

@ScriptedAlchemy @theKashey
Hey guys! Spent last few weeks hacking into wmf+loadable, and after playing around with what's available at the moment, there are still a few unsolved issues. Might require some more heavy plugin loading to fix them:

The first issue is explained in the comments to PR by DanielAmenou: https://github.com/module-federation/module-federation-examples/pull/1082#discussion_r727130871 . There is a tiny hack to preload wmf modules, so that loadable gets to see them, I believe it can be solved either by writing a dynamic mf resolver, or by giving loadable a basic idea on how to trigger mwf preload.
The second issue is a bit deeper, as circular loadable import does not work. Module federation can resolve them just fine, but when Importing mf1/comp -> mf2/comp -> mf1/anycomp, the chain doesn't work on SSR.

Alternatively both these issues can also be addressed by allowing WMF to run fully synchronously, currently the closest we can get is declaring filesystem path in ModuleFederationPlugin. But that still creates a require/promise chain of resolution, making the process asynchronous.
Any ideas on these? And it goes without telling that the combination of the two (WMF+loadable) seems like a number one candidate to the future of enterprise frontend architecture :)
So amazing job on supporting them.

If somebody else hits issue number 2, it is caused by using different instances of @loadable/component. Easiest way to fix it, is just adding @loadable/component to webpack.externals

As for the nested import, it's actually working server-side. As for client-side reverse lookup seems legit.
The other issue, although requires some attention. What I could dig up to this moment:
When one uses synchronous import import, the chunk gets bound to the parent chunk, that imports it (the right side of the diff), this way @loadable/component works. But when we remove synchronous import (left side of the diff), chunk is moved to another owner, aka  "mf2/Component", and loadable is unable to resolve it.

Sync imports also require extra tracking. So you have to know what chunks were user from a foreign build and apply those (reverse reverse lookup)

I'm thinking more about compilation-based solution. Since loadable itself turns async imports sync ones, and WMF is able to properly chain external packages as internal. Then there are two viable alternatives:

(straight solution) modify @loadable/component requireSync, so that it is able to resolve WMF modules. If for some reason entirely sync format is impossible, we can create server side loadableReady - that would await all the WMF remote chunks.
(hacky solution) modify @loadable/babel-plugin, so that it adds unused synchronous import next to @loadable call. This way during prebuild, it would tell WMF to bundle chunks closely for SSR.

What happens if remote imports more remotes?
Static import is one thing that has to be mapped, tho usually easy as long as something tells you want chunk ID was used to perform a reverse lookup. Remotes themselves would need to contain or report their nested async imports as well so loadable can find them and resolve them during the flush

What happens if remote imports more remotes?
Static import is one thing that has to be mapped, tho usually easy as long as something tells you want chunk ID was used to perform a reverse lookup. Remotes themselves would need to contain or report their nested async imports as well so loadable can find them and resolve them during the flush

I've tested remotes importing more remotes and it works fine server-side as long as static import is used alongside loadable call.
Uploaded a WIP PR with working 2nd solution: https://github.com/gregberge/loadable-components/pull/883
As for the first solution. I currently don't have enough understanding of how loadable performs requireSync. From what I do know tho, is that the component chunk (that crashes with call of undefined), actually gets executed in nodejs without synchronous call (which is super weird). So it seems to me that issue is not in the way WMF handles remote chunk resolution, but in how loadable accesses remote chunks, that are, in fact already loaded in webpack, but not in webpack_modules. I tried manually putting components in webpack_modules using dynamic WMF configuration, but for some reason components turned into a pumpking (empty JS object).

SSR part of Loadable really expects all referenced modules to support requireSync (because that's nodejs require works)
Adding static imports aids SSR, but makes one big monolith from the clientside application. This solution works, but does not provide the desired "splitting" functionality.
In order to support WMF we need to change API a little bit, as well as reconfigure babel plugin.
However all this time the main friction comes from webpack integration (loadable hooks into jsonpcallback).
I am afraid that probably the only way forward is to keep that actual "loadable-component", but totally rewrite everything else.

SSR part of Loadable really expects all referenced modules to support requireSync (because that's nodejs require works) Adding static imports aids SSR, but makes one big monolith from the clientside application. This solution works, but does not provide the desired "splitting" functionality.
In order to support WMF we need to change API a little bit, as well as reconfigure babel plugin. However all this time the main friction comes from webpack integration (loadable hooks into jsonpcallback).
I am afraid that probably the only way forward is to keep that actual "loadable-component", but totally rewrite everything else.

@theKashey That is not entirely right. Static import is the only way the current WMF example works in the first place. With module federation static is the new dynamic, it does not break chunk splitting, but it might actually modify when the chunks load.
i couldn’t make the application work on client side disabling the plugin, but we can detect if babel is bundling for the server and fix import there.

This is solvable. Unlikely we need a big rewrite.
after the enormous effort it took to get nextjs to work end to end with WFM altering a library will be much easier.
I can also change any aspect of module Federation. AOT manifest stitching won’t work. Like loadable, this must be done during execution.
Nothing stops me from replacing the entire webpack runtime, it’s like 3 plugins.
Someone PR my SSR example to repro the problem. In MF examples. From there we can organize some action.
I fail to see the roadblock based on my knowledge of loadable-like libraries and webpack mechanics.
Not easy, but not hard either

I don’t believe we need access to jsonp, but if we did.. it’s a plugin. I already use custom targets instead of target:node - at that point I’ve got complete control over every runtime requirement. Hooks don’t matter at that point. You are the webpack runtime in totality. I doubt we need to go that far though,

If it is impossible to make WMF modules available synchronously for requireSync consumption, we can modify CSR in loadable to use requireAsync for all the remotes. Then modify loadableReady to wait for chunks to be both pushed in LOADABLE_LOADED_CHUNKS object and actually resolved within requireAsync

Bare v8 like cloudflare or some other technology. One key note on those. Depending how you load code, code generation is not supported on edge vendors 😑 the nearest thing to sync I can manage is replace webpack filesystem. Rebuilt target async node it's still async but at the Fs level, not the framework level

Can’t we have a callback replacement for chuck loading? loadable is actually using such. Chunk is added during chunk code evaluation, which is calling loadable callback. So the wmf init/get can use simillar mechanic. Once you call ‘get’ if chunk is already loaded, it is returned synchronously

I probably wouldn’t deviate from the way we have WMF setup internally - since it already does return a sync function back when using require or static imports. But we can make a proxy module on the get,init call - essentially MF middleware

You can also replace the chunk load global inside webpack. Its a global variable like webpack_chunk_load
Similar to how you can change public path at runtime

I probably wouldn’t deviate from the way we have WMF setup internally - since it already does return a sync function back when using require or static imports. But we can make a proxy module on the get,init call - essentially MF middleware. Though webpack internally expects to receive a thennable, as it calls factory and get for us - but we can proxy call it, and upon returning the real get(), tell loadable something

Well, initially we had two paths to fix the issue:

allow remotes to run synchronously if their chunks are loaded externally;
tweak loadable to make up with asynchronous mwf;

And now this leaves us with 2nd choice, we can make a deeper dig into the issue now from loadable perspective.
So, how do I understand it, from the source code analysis:
The issue is taking root in the way loadable expects modules to be loaded once chunk loads. Thus loadableReady assumes that all those chunks are loaded and simply forces their require. What we should do instead, is make loadableReady not only wait for chunks to load, but also to perform async initialisation and wait for the promise, returned by the remote.get's

You can also replace the chunk load global inside webpack. Its a global variable like webpack_chunk_load Similar to how you can change public path at runtime

Don't really understand what you mean by that, or where that "chunk load global" is in the big picture :)

I believe I found a working approach, going to compile a solution soon. Not sure if it's a right place for it, but during loadable constructor calls (aka loadable(...)), it's possible to collect a global object with [chunkName]: importAsync calls. Then loadableReady will wait for Promise.all([...]), for each external chunk listed in __LOADABLE_REQUIRED_CHUNKS___ext.namedChunks

Okay, got it working both server- and client-side.
Got a question on which strategy do we take server-side?
Choice A: Pass extra option to babel-loader to inject static import (ssr: true), so that entire loading is handled by webpack bootstrap
Choice B: Make loadableReady call on required on the server. And then use same resolution as in the web, except it must do  a reverse-reverse require preload. For some reason I need to preload same components from different remotes.

@theKashey @ScriptedAlchemy Uploaded a PR with loadableReady turned into an async preloading foundation.
A lot of things still need to be tested, but it works in my setup. Also I did not actually "build" loadable yet. Just modified it inside node_modules. Then accurately copied the solution to the repository. Will soon check if the built version is working properly.

There is a little unknown moment around the way loadable names chunks - it has to be deterministic and the names has to be unique.
#885 seems to be capable resolving the root cause, but:

federated chunks will not be flushed during SSR, and I am not sure if it's even possible as due to WMF nature those names are not "static"
all federated modules will be loaded, regardless are used or not, leading to undesired results.

I’ll look into the first issue, but as for the second - with PR, i only request chunks gathered during SSR and passed to named chunks. As for deterministic names, not sure there is a problem, but I’ll try production builds, to see if the mapping is done right

Lol, found the problem with shared modules, its kinda laughable.
I declared React as shared in WMF. And loadable is using react internally. So It jamms into chicken/egg paradox.
WMF requires bootstrap to load eager dependencies, such as React. And loadable must wrap bootstrap, to gather chunks, which requires react.

We currently have two blockers, each with it's own proposed solution:
Problem 1. WMF eager static imports are generating chunks that loadable can't see.
Solution: Webpack uses async import boundaries to take its time and preload all the eager static imports. Meaning the dependencies are kept somewhere. WMF turns them into Promise.all like this:
 . We can extract them with webpack-plugin somehow and attach as dependencies to their async boundaries chunks. @ScriptedAlchemy can probably point us in the right direction - how to properly pinpoint eager static imports binding.
Problem 2. Top level async boundary - bootstrap. Loadable is meant to process components, there were no need to support regular imports. So we can't just loadable(() => import('./bootstrap')) if there is no react tree rendering, we can't extract the chunk.
Solution: basically "bootstrap" or top level async boundary is a synchronous pattern, there should be no "conditional" rendering to it compared to loadable components, thus we can just tell loadable to treat that chunk as one of those always required dependencies. To do so, I suggest introducing loadable.bootstrap(() => import('./bootstrap'))

I parse the MF plugin options, so i know everything about that plugin and if its shared or not.
I track what's loaded per request, so i dont load anything additional other than the execution tree. Preloading only 3-4 files that were actually used.
For vendors, in webpack they have a shared module type, so i can look at the stats of graph and find all the ids, chunks they live in, how its referenced.
This is a large portion of the magic that makes it work in next.js - might be some applications here, at least conceptually. The module id is a placeholder id, so you have to look past that key and know what's the chunk associated with it.
Async import bootstrap also solved many issues, but you'd still want to flush chunks out of SSR for maximum performance
https://gist.github.com/ScriptedAlchemy/7c1c7b25665524fbb0dfb4f06db7ebff

These shared modules, you'd want to know what came from where. I do this by tracking the initialization scopes which include what, and from who.

That's actually great news, meaning I'm on the right track. Or even on the right paved road!

I parse the MF plugin options, so i know everything about that plugin and if its shared or not.

Got that part from webpack stats as well, it has all the info about consumes and provides

I track what's loaded per request, so i dont load anything additional other than the execution tree. Preloading only 3-4 files that were actually used.

That's the magic done by loadable, don't really plan to take that bread, loadable tracks rendered components very well, only need to figure out how to let it track async initialization.

For vendors, in webpack they have a shared module type, so i can look at the stats of graph and find all the ids, chunks they live in, how its referenced.

That's what I spent whole yesterday doing, and only by the end of the day discovered there is a reason section inside webpack/sharing/consume chunks, that tells who uses what.

This is a large portion of the magic that makes it work in next.js - might be some applications here, at least conceptually. The module id is a placeholder id, so you have to look past that key and know what's the chunk associated with it.

Yep, that's the info I also got from the webpack.stats

Parsing reasons is pretty common.
Another thing to watch for is if it's shared code, you want to put it in the right parents in the map. So like react, I'd push its chunk into the array of files needed at entry point level. Otherwise things could double load.

Parsing reasons is pretty common.
Another thing to watch for is if it's shared code, you want to put it in the right parents in the map. So like react, I'd push its chunk into the array of files needed at entry point level. Otherwise things could double load.

Did not reach that part yet.
I planned to extract shared provides and shared consumes by chunks, and put them into loadable-stats. After that find a way to require what's needed the most. That approach will also simplify mf orchestration, since I can join multiple loadable-stats and dedupe shared even further.

Okay, been off the radar for a week doing other things, but now I'm back.
Finished working on Problem 1.: extracting WMF shared consumes and attaching them to chunks. Now chunks section is extended with sharedConsumes:

That in turn are listed in sharedModules section. All the data is extracted purely from stats.json via loadable/webpack-plugin

The next step is Problem 2: Telling loadable to extract async modules between entrypoint and App. As soon as I started thinking about that problem I've hit a multiple choice decision.
Prerequisites:

During chunk flushing, we tell wmf to use an entrypoint;
Chunks connected to react components wrapped by loadable are gathered during Server-Side Rendering;
Between 1 and 2 there is an async boundary: export default import('./bootstrap'), needed for WMF to collect eager depencendies;

So, there are at least 3 possible ways to proceed:
Choice 1: Using webpack stats, I can find all the async chunks between entrypoint and every loadable. Assuming the application only has one path from entrypoint, that would allow gathering these async chunks automatically with no extra boiler code;
Problems: what happens if there are more than one conditional path between? And what to consider the application root?
Possible Solutions: We could hypothetically throw a warning that there is more than one possible import path, so extra chunks are flushed and fix. The first chunk registered by ChunkExtractor can be considered the root chunk.
Choice 2: I could add loadable.bootstrap(() => import('./bootstrap')), this way we know exactly which path to take, or do we?
Problems: client and server usually have different entry points. So the bootstrap call flushed on the server will not match the call on the client.
Possible Solutions: It's ugly, but we could attach a key argument for bootstrap call, in case they don`t match (and if there are more than one bootstrap in the entrypoint).
Choice 3: We could have a loadable wrapper at application root, this way we would definitely know which chunk contains the root of application. This solution does not involve much changing to loadable mechanics, since ChunkExtractor can already work well with react components
Problems: This approach will not work if there are multiple async boundaries between entrypoint and application root.
Possible Solutions: Restrict making multiple boundaries? Combine with solutions for 1/2?

Did some reading of @loadable/babel-plugin contents and to be honest, I'm lost. From the way it is currently implemented, I am not sure what needs to be done next.
If we agree choice 2 is is the optimal way, we just need to add new loadable.bootstrap function. That function would have to be transformed the same way loadable component operates. Thing is, I don't need to actually change the async chunk with a component, not even sure I need to meddle with the chunk name. But I do need to somehow mark that import or bind it to the the react app part. And that binding has to work even if there are no loadable components on the other side.
Tinkering with babel-plugin AST is complicated enough as it is, not to go around experimenting, trying to figure out what has to be done.

So, there are at least 3 possible ways to proceed:
Choice 1: Using webpack stats, I can find all the async chunks between entrypoint and every loadable. Assuming the application only has one path from entrypoint, that would allow gathering these async chunks automatically with no extra boiler code; Problems: what happens if there are more than one conditional path between? And what to consider the application root? Possible Solutions: We could hypothetically throw a warning that there is more than one possible import path, so extra chunks are flushed and fix. The first chunk registered by ChunkExtractor can be considered the root chunk.
Choice 2: I could add loadable.bootstrap(() => import('./bootstrap')), this way we know exactly which path to take, or do we? Problems: client and server usually have different entry points. So the bootstrap call flushed on the server will not match the call on the client. Possible Solutions: It's ugly, but we could attach a key argument for bootstrap call, in case they don`t match (and if there is more than one bootstrap in the entrypoint).
Choice 3: We could have a loadable wrapper at application root, this way we would definitely know which chunk contains the root of application. This solution does not involve much changing to loadable mechanics, since ChunkExtractor can already work well with react components Problems: This approach will not work if there are multiple async boundaries between entrypoint and application root. Possible Solutions: Restrict making multiple boundaries? Combine with solutions for 1/2?
I don’t like choice 1 as it becomes uncontrollable and unpredictable. Choice 3 has a rather bad limitation.
So I favor the 2nd choice. We could also combine 2 and 1. Aka use bootstrap to tie down entrypoint with application root. But build the path from entrypoint to the root via webpack stats, following available client-bundle bootstraps.

Covering edge cases, I got the following results:

Choice 1. Will NOT work. If we have an app that does not consume any loadable ssr components, but still use wmf shared and async boundary, we will not be able to determine find all the async boundaries between App and entry, because we would have no loadable calls within App;
The above is handled by choice 3 properly, but there is still the limitations of multiple async points. For now the only solution I see is choice 2. Naming async boundaries would both let us support complex cases such as different bootstrap path for client and server and give toolset for manual manipulation.

Going deeper into the current goals for choice 2 solution:

Our main goal is to capture the imported chunk names for all the bootstrap calls;
To capture it during runtime and not compile time, we can proxy import's thenable. When 'then' is called, we add the chunk to the ChunkExtractor;
Proxied then call happens between ChunkExtractor initialization and collectChunks call;
We might require multiple bootstrap calls for client for every bootstrap call on the server and vice versa;
Loadable keeps deterministic naming for all the chunks, in our case, we should give bootstraps special names based on both given key and path. If key exists, we'll be matching part of the chunkName representing the key, otherwise, we check against the path;

So from what I see, we can do something like: LoadableBootstrap__src_components_index_jsx for path-related keys and "LoadableBootstrap_some_key__src_components_index_jsx" for keys. Alternatively, I'm not sure if we need to rename chunks at all. Why can't we just gather them during thenable call with their given names/keys. It's not like we actually need to do the loadable magic for sync/async call later on, they are only needed for the flushing.
I'll spend some more time clearing out why's and how's chunkName replacement works in loadable/babel-plugin and then try to implement that bootstrap utility.

Got some great news:

I was able to implement the loadable.bootstrap function. Funny enough that function only contains warning that it should not be called without babel plugin. Babel plugin replaces the function call entirely with an iife that returns thenable. Once that thenable is resolved it both pushes the bootstrap chunk to global object stack and calls the async import;
Having loadable.bootstrap completely replaced fixes the "chicken-and-egg" problem, initial chunk no longer depends on loadable nor react, so we can separate loadable and react into WMF shared dependencies entirely;
I did some analysis on babel-plugin chunk name generation and bumped into the issue which apparently was already raised before: https://github.com/gregberge/loadable-components/issues/549. Posted a simple solution that will fix the collision, also with some work the very same solution may fix collision between different mfs;

What's left to do:

The working loadable.bootstrap tells that a bootstrap chunk is loaded, but there are still no ways to merge them, since there can be multiple bootstrap chunks SSR and CSR. Furthermore, we can't call these bootstraps passing same variable and expect them to match, unless we just pass string literal with bootstrap name;
The naming issue above requires resolving;
Need to enhance loadable SSR toolkit to allow joining multiple loadable-stats into a single united stats, so that chunk mechanics works out of the box without external scripts and plugins;
Documentation, optimization, tests, examples, etc.

Finally finished the async bootstrap chunk registration, It was harder than I thought and required me to do a little hack with unused export const __LOADABLE_MARKER_BOOTSTRAP__${chunkName} marker. I decided to keep things simple: no dynamic bootstrap chunk, if you call loadable.bootstrap(() => import('./path/to/bootstrap')), that chunk will always be bundled with the chunk that imported it.
Now switched to enhancing ChunkExtractor, to make it properly use loadable stats for registering both bootstrap- and wmf shared chunks.

@theKashey ever thought about rewriting loadable-stats, so that it only contained fields required by loadable? We could reduce the load on ChunkExtractor and remove a lot of unnecessary data in the stats file without breaking backwards compatibility (unless somebody parsed the stats manually outside ChunkExtractor). If somebody needs some extra data in loadable-stats, they should ask for it with plugin configuration.
Also quite literally holding myself back from rewriting ChunkExtractor towards respect for SingleResponsibility.

ever thought about rewriting loadable-stats, so that it only contained fields required by loadable?

I also hold the same idea for a long time - https://github.com/gregberge/loadable-components/pull/778#issuecomment-849165455
It was "reduced" multiple times:

https://github.com/gregberge/loadable-components/pull/708
https://github.com/gregberge/loadable-components/pull/510

And increased as well:

https://github.com/gregberge/loadable-components/pull/779

But we are subject for hurim law and should just create another version of Chunk Extractor with the another "API"/"Goal" set initially ( well, https://github.com/theKashey/webpack-imported )

finished the async bootstrap chunk registration, It was harder than I thought

And probably the same can and should be applied to the loadable-component themselves. I don't feel that the current model is actually clicking with Federation and one might need to find another model.
For example create that new ChunkExtractor and make it a part of ModuleFederation - ie let servers share this information, not to make it somehow discoverable on the frontend.
No changes to the MF is required. "Loadable" should just discover federated modules(you did it) and then discover "Loadable" inside them. Repeat until success.

But we are subject for hurim law and should just create another version of Chunk Extractor with the another "API"/"Goal" set initially ( well, https://github.com/theKashey/webpack-imported )

It feels overwhelmingly wrong to create another plugin, just to allow loadable to simplify stats. It also feels wrong to create 2 stats files by loadable. So what I had in mind, was major release, with a new flag that allows for minimum stats, eventually switching that flag defaulting to minimal stats.
For now, It feels I'm violating pioneers rule, by adding 2 new methods to already overbloated ChunkExtractor class, I'm leaving something in worse state then it was. Guess that's what open source is like, your every step feels like walking on a mine field :)

It feels overwhelmingly wrong to create another plugin

Unfortunately, stats generated by loadable as over and misused already. Releasing a major version of plugin and introducing the breaking change in the API might break some integrations.
So this can be done only with recommended replacement, a clear migration guide, and the minimal API surface from day 1, as switching that flag defaulting to minimal stats will introduce another breaking change.

Thus I want to ask you - what exactly you need to change? What if in any circumstances the best way forward is creating a special MF-friendly version of ChunkExtractor and Loadable.bootstrap code?
Do anyone not using MF will benefit from the change or it's actually better to keep things detangled?

Let's move that discussion to the moment when initial implementation is done in pull request. Need to focus on the task first, then we'll see if some suggestions are worth doing.
As for your questions:

bootstrap will be usable for people not using mf, as it allows binding multiple asynchronous chunks together, some task may require this;
Cleaning up loadable stats size would allow us to reduce size by 2 to 4 times, could be useful to others too;

Did not abandon the project :) Just got my hands busy elsewhere.
Got a bit of a progress before I had to switch. Both positive and negative.
First for the bad parts:

Tried out production build, as all the moduleIds got replaced with numeric values, some of the parts stopped working, especially all the checks against federated id's; rewrote a couple of checks to another field (aka identifier), but one of the checks, "isFederated" could not be rewritten. It happens during runtime, but we do not have any info on other ids at that time. So unfortunately, to detect federated chunks, the schema has to be even more complicated: got to collect all the federated chunks during webpack build and output them into the client;
Working with shared wmf dependencies also proved more difficult, than I thought. Instead of blindly collecting all the related chunks, I found out that inside webpack stats chunks: [...] arrays within modules represent all the chunks that include a copy of the module. So now we have to thoroughly analyze which chunks are already accumulated and ignore them. To add another nail, the common chunks must actually match the ones added during server build;
Since we need to match some "unknown" chunk inclusion algorithm, we need to render single entrypoint on the client (without extra preloads), see what WMF includes on it's own. Save that order and then compare it against the order we have with LOADABLE_REQUIRED scripts.
Having this in mind, I decided to go for TDD: added jest-puppeteer, configured it out a bit, ran into a trouble with conflicting configurations, started resolving against jsdom that was already used, till I figured out that jsdom is a better fitting solution for the task. And it actually works well with WMF client-side, I got the scripts that WMF loads, just need to clean up my prototype and turn it into an example inside loadable repository;
And the final thumb down goes with remoteEntry.js, analyzing webpack stats, shared dependencies and files WMF loads, It seems remoteEntry.js is out of all those pictures, so we probably have to require it manually just before requiring any of the  remote chunks;

To summarize, the goal yet again got pushed away by a few weeks of development :)

Any progress on this? Seems to break razzle builds (hash mismatch on production build)

Unfortunately, I just spent half of my day realizing that this happens when you use webpack 5 or above. Once you downgrade back to webpack 4 it functions normally.

Razzle is quite unstable with wp5, needs help with rewrite btw ;)

How I got this to work for next.js was to embed the loadable stats into the remote entry’s runtime. So I have get,init,chunks - then at runtime I’ll collect the chunks from each remote that it’s exporting, then merge them with the known loadable manifest.
For module ids. I didn’t have to worry about that, they were registered as the ids from the other container and merging the manifests at runtime provided the lookups I needed.
Ontop of that, I’ve also changed how remote module is loaded, so when a remote modules get or init apis are called, I’ve got hooks into that and can see “who loaded what” so as it’s executing webpack is pushing requests into a queue that I can flush after render by getting the remotes chunk maps with global.remote.chunkMap

The hook "who loaded what" seems like some new webpack event? Gave this whole thing a little thought and what's really holding the implementaion back - is WMF awesome async boundary, that just loads whatever it needs (hardcoded as Promise.all in resulting bundle). If that thing could be exposed, it would make things much easier.


Bug report: Can't install obs: pkg source file not found

Description of issue
OBS had a major upgrade recently implemented in https://github.com/caskroom/homebrew-cask/pull/31296. It won't install for me, possibly related to that it changed from a pkg within a dmg to a raw pkg.
Output of `brew cask  --verbose`
% brew cask install obs --verbose
==> Downloading https://github.com/jp9000/obs-studio/releases/download/18.0.1/obs-mac-18.0.1-installer.pkg
Already downloaded: /Users/alex/Library/Caches/Homebrew/Cask/obs--18.0.1.pkg
==> Verifying checksum for Cask obs
==> Running installer for obs; your password may be necessary.
==> Package installers may write to any location; options such as --appdir are ignored.
Error: pkg source file not found: '/opt/homebrew-cask/Caskroom/obs/18.0.1/OBS.pkg'
Error: nothing to install
Error: Kernel.exit

Output of `brew doctor`
% brew doctor
Please note that these warnings are just used to help the Homebrew maintainers
with debugging if you file an issue. If everything you use Homebrew for is
working fine: please don't worry and just ignore them. Thanks!

Warning: Anaconda is known to frequently break Homebrew builds, including Vim and
MacVim, due to bundling many duplicates of system and Homebrew-available
tools.

If you encounter a build failure please temporarily remove Anaconda
from your $PATH and attempt the build again prior to reporting the
failure to us. Thanks!

Warning: "config" scripts exist outside your system or Homebrew directories.
`./configure` scripts often look for *-config scripts to determine if
software packages are installed, and what additional flags to use when
compiling and linking.

Having additional scripts in your path can confuse software installed via
Homebrew if the config script overrides a system or Homebrew provided
script of the same name. We found the following "config" scripts:
  /Users/alex/anaconda/bin/curl-config
  /Users/alex/anaconda/bin/freetype-config
  /Users/alex/anaconda/bin/icu-config
  /Users/alex/anaconda/bin/libdynd-config
  /Users/alex/anaconda/bin/libpng-config
  /Users/alex/anaconda/bin/libpng16-config
  /Users/alex/anaconda/bin/python-config
  /Users/alex/anaconda/bin/python2-config
  /Users/alex/anaconda/bin/python2.7-config
  /Users/alex/anaconda/bin/xml2-config
  /Users/alex/anaconda/bin/xslt-config
  /usr/local/pspdev/bin/psp-config

Warning: Python is installed at /Library/Frameworks/Python.framework

Homebrew only supports building against the System-provided Python or a
brewed Python. In particular, Pythons installed to /Library can interfere
with other software installs.

Warning: You have MacPorts or Fink installed:
  /opt/local/bin/port

This can cause trouble. You don't have to uninstall them, but you may want to
temporarily move them out of the way, e.g.

  sudo mv /opt/local ~/macports

Warning: You have unlinked kegs in your Cellar
Leaving kegs unlinked can lead to build-trouble and cause brews that depend on
those kegs to fail to run properly once built. Run `brew link` on these:
  python
  root6

Warning: You have a curlrc file
If you have trouble downloading packages with Homebrew, then maybe this
is the problem? If the following command doesn't work, then try removing
your curlrc:
  curl https://github.com

Warning: Homebrew's sbin was not found in your PATH but you have installed
formulae that put executables in /usr/local/sbin.
Consider setting the PATH for example like so
  echo 'export PATH="/usr/local/sbin:$PATH"' >> ~/.zshrc

Warning: Some installed formula are missing dependencies.
You should `brew install` the missing dependencies:
  brew install rarian

Run `brew missing` for more details.

Output of `brew cask doctor`
% brew cask doctor
==> Homebrew-Cask Version
Homebrew-Cask 1.1.11-170-g09231dd52
caskroom/homebrew-cask (git revision b9bab; last commit 2017-03-26)
==> Homebrew-Cask Install Location
<NONE>
==> Homebrew-Cask Staging Location
/opt/homebrew-cask/Caskroom
==> Homebrew-Cask Cached Downloads
~/Library/Caches/Homebrew/Cask (5 files, 166.3MB)
==> Homebrew-Cask Taps:
/usr/local/Homebrew/Library/Taps/caskroom/homebrew-cask (3614 casks)
/usr/local/Homebrew/Library/Taps/caskroom/homebrew-drivers (46 casks)
/usr/local/Homebrew/Library/Taps/caskroom/homebrew-versions (176 casks)
/usr/local/Homebrew/Library/Taps/homebrew/homebrew-bundle (0 casks)
/usr/local/Homebrew/Library/Taps/homebrew/homebrew-core (0 casks)
/usr/local/Homebrew/Library/Taps/homebrew/homebrew-dupes (0 casks)
/usr/local/Homebrew/Library/Taps/homebrew/homebrew-games (0 casks)
/usr/local/Homebrew/Library/Taps/homebrew/homebrew-gui (0 casks)
/usr/local/Homebrew/Library/Taps/homebrew/homebrew-science (0 casks)
==> Contents of $LOAD_PATH
/usr/local/Homebrew/Library/Homebrew/cask/lib
/usr/local/Homebrew/Library/Homebrew
/Library/Ruby/Site/2.0.0
/Library/Ruby/Site/2.0.0/x86_64-darwin16
/Library/Ruby/Site/2.0.0/universal-darwin16
/Library/Ruby/Site
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/vendor_ruby/2.0.0
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/vendor_ruby/2.0.0/x86_64-darwin16
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/vendor_ruby/2.0.0/universal-darwin16
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/vendor_ruby
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/x86_64-darwin16
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/universal-darwin16
==> Environment Variables
LANG="en_US.UTF-8"
LC_CTYPE="en_US.UTF-8"
PATH="~/anaconda/bin:~/local/sbin:~/local/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/usr/local/git/bin:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/Library/TeX/texbin:/Applications/Wireshark.app/Contents/MacOS:/usr/local/pspdev/bin:/usr/local/Homebrew/Library/Taps/homebrew/homebrew-bundle/cmd:/usr/local/Homebrew/Library/Homebrew/shims/scm"
SHELL="/bin/zsh"

From the issue template that shows when opening a new issue:

Before opening your issue you must check our instructions for reporting bugs (…) [it] has several links to help diagnose and fix common issues.
(…)
if it is apparent you ignored the instructions for reporting issues, we may close the issue without review.

That seems to be the case, which is why I closed this issue. We worked hard  on those guides to keep things running smoothly, so I ask that you go back and follow them. It is OK to open a new issue for that.
If I was wrong in closing this issue, please do reply stating why! Closing an issue does not mean the conversation is over.
I understand sometimes we’re tired and don’t want to sift through a guide to make what we feel is a simple bug report. But when each user ignores the guides to save a few minutes, maintainers lose hours and get fatigued. I ask you take that into consideration.
Thank you for understanding.

I am not sure what your problem is with my issue. Could you please clarify?

There’s a section of the reporting bugs instruction specifically geared for this.


fix(esl-media): ref: prefix is optional, user should be able to use  internal id

:tada: This PR is included in version 4.3.0-next.1 :tada:
The release is available on:

npm package (@next dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 4.3.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


fix(ci): pin golangci-lint to v1.21.0

should fix the issue in master with building golangci-lint during a CI run. See #6941.
Will need to cherry-pick this into the 3.0 branch to ensure CI runs will succeed.
https://github.com/golangci/golangci-lint#go-get
Signed-off-by: Matthew Fisher<EMAIL_ADDRESS>

still lgtm to merge.


Revision of proposal 0126-ATF-Additional-Transports

@aderiabin why did you remove the diagram? As I can see it is still used in the proposal. Probably you should provide an updated diagram?

@AKalinich-Luxoft Regarding the comment:

why did you remove the diagram? As I can see it is still used in the proposal. Probably you should provide an updated diagram?

I'm able to see a new diagram if new version of proposal is opened by link https://github.com/LuxoftSDL/sdl_evolution/blob/8f780a2b5f652d4a5b675dcd6cb789a3b0452244/proposals/0126-atf-additional-transports.md


About Enhancement and Responsiveness added

Closes: #156

Title :  Image size fix/Responsive/Content Addition
Name: Bhavy Zala
Idenitfy yourself: Gssoc'24

Describe the add-ons or changes you've made 📃
I have give proper size of image in big screen and in small screen.
Add Content in About Chanakya with quotes.
Make page responsive with text and image.
Type of change ☑

What sort of change have you made:

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[x] Code style update (formatting, local variables)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

Checklist: ☑

[x] My code follows the Contributing Guidelines & Code of Conduct of this project.
[x] This PR does not contain plagiarized content.
[x] I have performed a self-review of my own code.
[x] I have commented my code, particularly wherever it was hard to understand.
[x] My changes generate no new warnings.

Screenshots 📷
https://www.loom.com/share/a56ff9ca5bf845e0896b77a25fa28e69

@Avdhesh-Varshney Please check it and merge !


Execute remote command as root

I must be missing something obvious, sorry. Is there a way to execute a remote command as root/sudo? Normally ssh -t would help but I cant find a way to do that. Can anyone help please?

Hello, I've set up bigssh to execute a simple "sudo id" and it works...
I needs your user to be sudoer on the remote system

It seems ok for simple commands but not to run a shell script as su. Not to worry, I found another way. Thanks.


[FLINK-13978] Add azure-pipelines.yml

What is the purpose of the change

Introduce an azure-pipelines.yml file, so that we can trigger Azure Pipelines builds from flink-ci/flink.

Thanks


Add a column (editor)

Done but need to save and reload to achieve.
In the other case the header is correctly inserted, but the data don't shift and the new data column (at the end) is fulled by some magic one digit random number (they are not save, so they are not reloaded).


Missing Stratis RPC methods for integrating with NBitcoin AltCoin test framework

The NBitcoin AltCoin test framework uses RPC on a regtest daemon. The following RPC functions are used:

GetBlock
Generate
GetBestBlockHash
getnewaddress
validateaddress (DONE)
sendtoaddress (DONE)
getrawtransaction (DONE)
sendrawtransaction

getblock
generate (MiningRPCController)
getbestblockhash (ConsensusController)
getnewaddress
validateaddress (DONE) (FullNodeController)
sendtoaddress (DONE) (WalletRPCController)
getrawtransaction (DONE) (FullNodeController)
sendrawtransaction

The current approach allows new features to be added together with any RPC methods that they contribute - i.e. it does not require updating any code that is shared between features.

Yes agreed, though we have the api feature for that.
RPC I would hope will slowly become less used and we only support it for legacy reasons.

The current architecture leads to dependencies on the RPC feature like below:
public static IFullNodeBuilder AddPowPosMining(this IFullNodeBuilder fullNodeBuilder)
        {
            LoggingConfiguration.RegisterFeatureNamespace<MiningFeature>("mining");

            fullNodeBuilder.ConfigureFeature(features =>
            {
                features
                    .AddFeature<MiningFeature>()
                    .DependOn<MempoolFeature>()
                    .DependOn<RPCFeature>()
                    .DependOn<WalletFeature>()
                    .FeatureServices(services =>
                    {
                        services.AddSingleton<IPowMining, PowMining>();
                        services.AddSingleton<IPosMinting, PosMinting>();
                        services.AddSingleton<IBlockProvider, BlockProvider>();
                        services.AddSingleton<BlockDefinition, PowBlockDefinition>();
                        services.AddSingleton<BlockDefinition, PosBlockDefinition>();
                        services.AddSingleton<BlockDefinition, PosPowBlockDefinition>();
                        services.AddSingleton<StakingRpcController>();
                        services.AddSingleton<StakingController>();
                        services.AddSingleton<MiningRpcController>();
                        services.AddSingleton<MiningController>();
                        services.AddSingleton<MinerSettings>();
                    });
            });

            return fullNodeBuilder;
        }

If we truly want RPC to be pluggable then it should be the other way around. RPC should depend on the features it needs and have the controller in the RPC feature.
If we want to treat RPC as kind of core component (not pluggable) then it makes sense to have RPC controllers in the individual features.
I'm in the midst of adding some more methods according to @quantumagi suggestions above. Is this what we want to do?
@dangershony

After looking into this I think I agree with dangershony, I'm not sure coupling the RPC feature to all the features like above is a good idea.  If we want to make RPC pluggable we should create a separate feature like "Stratis.Bitcoin.Features.Miner.RPC" that has RPC controller for the miner feature.
But for now the easiest approach without re-architecting some of this is to add:
getblock -> FullNodeController (it already has reference to blockstore)
getnewaddress, sendrawtransaction -> WalletRPCController (it already has references to wallet stuff)

Also need to add:
sendtoaddress -> WalletRPCController
Currently only a stub there, it doesn't actually work.

Also need to add:
gettransaction
getbalance


More than one id generator

Overview of the issue

If more than one id generator is used in the diagram, an error is generated. However, if done by hand it is valid.

Hi @jamematen,
Please share an example with source code, I tried to reproduce by adding the different generator to entities and source code is generated without issue. But If multiple generators added to the same entity then the error popup shown.


Add Lightning Network filter

Add custom made TxFilter() to scan for Lightning Network channels.

With the new filter system this should be now much easier.


an error in qlib/data/dataset/handler.py  at line 518

    if self.process_type == DataHandlerLP.PTYPE_I:
        _learn_df = _shared_df

@ning213 Hi,
What are the specific errors?

    # data processing flow of self.process_type == DataHandlerLP.PTYPE_I
    (self._data)-[shared_processors]-(_shared_df)-[learn_processors]-(_learn_df)
                                           \
                                            -[infer_processors]-(_infer_df)

157     if self.process_type == DataHandlerLP.PTYPE_I:
158        _learn_df = self._data

@ning213
Thanks for your reporting this bug!
Will this PR fix your issue?

@

@ning213 Thanks for your reporting this bug! Will this PR fix your issue?

yes, thanks


Setting an Area as cleared in the save editor Locks the dungeon if it requires a Song

[x] I have checked the known issues and searched Github to ensure this issue has not already been reported.
[x] This is not a feature request, I know those belong on Discord/Github Discussions.

Description of the bug:
=The Save Editors "area clear" function bugs woodfall and great bay rendering their dungeons inaccessible.
Can you reproduce? If so please list the steps:

[x] Yes, here are the steps to reproduce the bug:

-1. Go to... Save editor on a new cycle
-2. Do this...Check "woodfall clear" or "great bay clear"
-3. See the bug: woodfall remains sunk and the turtle that takes you to great bay isn't active. playing the required song does nothing
Expected behavior:

Woodfall and Great bay temples should be accessible
Screenshots or videos:

System Information:

OS:Windows 11
GFX Backend: OpenGL,
Game Version:Nightly
Rom Version: Majora's mask (U) 1.0

Additional Information:

Playing Sonata at Woodall sets WEEKEVENTREG_20_01.
Playing Bossa for Lulu sets WEEKEVENTREG_53_20 and WEEKEVENTREG_93_08.
I think 53_20 sets the turtle and 93_08 determines whether to play a long or short version of the cutscene.

Another one that didn't auto close.


cannot define NULL

Describe the bug
if I want to define NULL I get INCORRECT_DEFINE for any value in define
Erroneous code
#define NULL 0

norminette returns:
Error: INCORRECT_DEFINE     (line:   1, col:   7):	Incorrect values in define

Additional infos

OS: Linuxmint 20.2 uma
python --version: Python 3.8.10
norminette -v: norminette 3.3.32

Hello,
For now, NULL is not considered a valid identifier, as in most cases, it's already defined by various includes. Only non-existing identifier can be defined with the norminette


📣 Voting for 1.0.0 release approval

The OpenAPI Overlay Specification is ready for release. In order for this to happen, 2/3 of the @OAI/tsc must "vote" to approve the release of the new specification.
Since it's the first release of the specification, there's no big merge PR for the new version - everything is on the main branch.

read the Overlay 1.0.0 specification
check the release notes in the draft release on the releases page

Please add your approval in the form of a comment on this issue.

Approved

I approve this release.

I also approve this release!

Vote CLOSED. Further changes were made to the specification so we'll need to restart the vote - there are other changes that are ready to include as well so let's stop, regroup, and then decide if we want to retry.

I approve!

I approve the modified version 1.0.0

Approved

I am good.

Approved

Re-opened now that the spec is updated

Also I approve!

Approve

Released! I'll close this issue.


Fix crash in 3259, add test

Summary
Fix crash when evaluating flags with nil GoFeatureFlag interface.  This is an interface of type go-feature-flag.Provider, with a nil value.  The interface itself is not nil, because it has the type stored.
Fixes #3259
Change Type
Mark the type of change your PR introduces:

[x] Bug fix (resolves an issue without affecting existing features)
[ ] Feature (adds new functionality without breaking changes)
[ ] Breaking change (may impact existing functionalities or require documentation updates)
[ ] Documentation (updates or additions to documentation)
[ ] Refactoring or test improvements (no bug fixes or new functionality)

Testing
Added unit tests, verified they reproduced the panic, then fixed the panic.
Review Checklist:

[x] Reviewed my own code for quality and clarity.
[x] Added comments to complex or tricky code sections.
[x] Updated any affected documentation.
[x] Included tests that validate the fix or feature.
[x] Checked that related changes are merged.

coverage: 50.314% (+0.1%) from 50.189%
when pulling 9b6b3a1123751374a194bd2702db99b0cb0dc1f8 on evankanderson:3259-segfault-when-doing-role-assignment
into e2414bc9d5836d99229260114837fb4e2ef01ec5 on stacklok:main.


added  letter t

added letter t : BOOMER
closes #63

Everything works fine. Thanks for contributing @ankitkujur15 😊

I'm glad I could contribute!


Hit a few more paths in http_server_filter.c, sockaddr_resolver.c

Such red, much failures.

Hit rebuild.

Rebuilding
On Fri, Dec 11, 2015 at 8:01 PM Nicolas Noble<EMAIL_ADDRESS>wrote:

Such red, much failures.
—
Reply to this email directly or view it on GitHub
https://github.com/grpc/grpc/pull/4420#issuecomment-164108042.


The idea of full-frames attention shares a great similarity with the spatial-temporal modeling approach used in Vid2Vid-Zeros.

If I could be wrong, the full-frame attention is similar to https://github.com/baaivision/vid2vid-zero.

thank you for your elaborate response.

I have also assessed the performance of depth control in comparison to two comparable video generation studies. The Videocomposer performs quite well.
resolution at 256*256
videocomposer:
{"fid50k_full": 32.85220698351932} {"fvd2048_16f":<PHONE_NUMBER>0087384}
controlvideo (https://github.com/YBYBZhang/ControlVideo)
{"fid50k_full": 53.00012164453821}, {"fvd2048_16f":<PHONE_NUMBER>664312}
control-a-video (https://github.com/Weifeng-Chen/control-a-video)
{"fid50k_full": 43.23543254253663} {"fvd2048_16f":<PHONE_NUMBER>700448}


Fixed transaction page view issue and icon issue in RTL

Issue Reference
Fixed transaction page view issue and icon issue in RTL

Checked and found that the issue has been fixed, now we are able to see the  transaction action details appearing. Please check the video for reference.
Video
https://github.com/bagisto/bagisto/assets/92721837/a93f4234-9cc6-4b4d-8f41-fb1c3eb9d1c0


Optimize asset state management

Overview
A significant performance bottleneck has been discovered due to updates in the asset list triggering a domino effect of selector recalculations. This results in extensive rerendering across the application, exacerbating performance issues.
The current structure consolidates all assets into a single list. As new portfolio assets and non-fungible assets are integrated, they are merged into this collective list. This action triggers a chain reaction where all related selectors and components undergo recursive recomputation.
To mitigate excessive recalculations, we recommend segregating the static asset list from the dynamically added assets. This separation will significantly reduce unnecessary recomputations since the applications for static and dynamic assets are largely distinct. This strategy aims to streamline performance by minimizing the computational overhead associated with asset updates.
References and additional details
Will require #6289 to fully realize the performance benefit.
Acceptance Criteria
Static asset list is stored in redux, and is never modified throughout the lifetime of the application.
Need By Date
No response
Screenshots/Mockups
No response
Estimated effort
No response

Closing with #6281 for details see:
https://github.com/shapeshift/web/pull/6281#issuecomment-2019095245


incorrect documentation

Dear developers, such disgusting documentation as you have in the project I have not seen anywhere else. You give your product as a "black box" and still write incorrect documentation for customization!
Example:
*
import NumberField from 'admin-config/lib/Field/NumberField';
class AmountField extends NumberField {
constructor(name) {
super(name);
this._currency = '$';
}
currency(currency) {
if (!arguments.length) return this._currency;
this._currency = currency;
return this;
}
}
export default AmountField;
*/
However, if I do exactly as you suggest then the system will fail, because your component is waiting a constructor from me, that will be stored directly in registered through a provider, same name property. I.e. export should be as flws: exports["default"] = my class ; module.exports = exports["default»];
You further advise on the creation of a widget for a custom field type and again give incorrect advice on how to connect. In this case, errors in the console drop out incoherently: a[y] is not a function  or: e_typeField is not constructor.
An these are only few of many examples of errors. There are too much errors, literally on every page. I am very disappointed that got involved with your product.

Dear embittered developer,

You give your product as a "black box"...

Thanks for using our open-source project. Because, yes, you have access to the whole code source and documentation on GitHub. We promise (and you can check it), there is no hidden call to our servers, nor keylogging features to steal your data. We just released it for free (as in beer and as in software) to help the community releasing awesome projects with less efforts.

...and still write incorrect documentation for customization.

We are sorry to hear that. Indeed, we are humans, and are committing some mistakes. Yet, we swear we are doing our best to deliver the most up-to-date and error prone documentation ever. If you detect some errors, feel free to submit a pull request. It would take far less time than writing such a long and constructive issue, and would be useful to everyone.

i.e. export should be as flws: exports["default"] = my class ; module.exports = exports["default»];

I am not sure to understand well your problem however. Is the module.exports missing in your code in order to make it work? If so, that's more a Babel transpilation issue. Indeed, we should mention if requires the babel-plugin-add-module-exports plug-in. That's a good idea. We are going to add it in the documentation shortly. :)
As a final note, just remember we are a team of volunteers spending some of our time on this open-source product, for free.  ;)

You guys build a very useful tool and I for one am very grateful for your efforts!
Thanks!


Add methods to Status

The following methods can be added to Status

[ ] toResponse which converts the Status to a Response
[ ] toApp which converts the Status to HttpApp

The following methods can be added to Status

[ ]  toResponse which converts the Status to a Response
[ ]  toApp which converts the Status to HttpApp

Hi @tusharmath, just created PR #577,
I'm not sure if there are more implications or other considerations, feel free to discard it if's not valid.


Is tagStandard41h12 supported?

Hi, thanks for publishing the code.
The link below says this, but is there any change in the types of tags that are still supported?
In the 2018.3 release, the tag36h11 tag family is supported. Extending the algorithm to other tag families is planned for a future release.
https://docs.nvidia.com/isaac/packages/fiducials/doc/apriltags.html
I would like to know if tagStandard41h12 is supported.

No, we have not extended support for more tag families beyond tag36h11. Is there any particular reason you wanted to use tag family 41h12 though?

Thank you for reply.
There is no particular reason. I will also consider changing the tag type.


[Feature]: Support HuggingFaceM4/idefics2-8b as vision model

🚀 The feature, motivation and pitch
I know even llava 1.6 isn't in, but benchmarks for this model are much better.
https://huggingface.co/HuggingFaceM4/idefics2-8b
https://huggingface.co/blog/idefics2

TGI support coming according to model card discussion, but no PR in TGI yet for 2, but seems idefics is there.
Alternatives
llava1.6, but maybe obsolete by now.
Additional context
No response

I will work on implementing this model.

Any progress on this?

Any update here? Thanks.


Java language version

what Java language version are you targeting?
Can you successfully parse lambdas and method references?
Thank you

Hello @LeanderK!
The target is the AP subset, it's now described here I'm not sure if they changed the subset from February but I don't think so, I checked quickly and it looks like the same 😄 !
So no lambdas…
Also as far as I remember there's an issue with private methods because JavaScript (ECMAScript 5 original target) used to handle privates in a very differently from how JAVA handles privates…

ok, thank you for your Help!


Release celllxgene-schema 2.1.0 to Test PyPI and PyPI

Follow the instructions below to release cellxgene-schema 2.1.0 to Test PyPI and then to PyPI:

https://github.com/chanzuckerberg/single-cell-curation/blob/main/docs/release_process.md#how-to-release-the-next-version-of-cellxgene-schema

cellxgene-schema 2.1.0 released to both Test PyPI and PyPI:

https://test.pypi.org/project/cellxgene-schema/2.1.0/
https://pypi.org/project/cellxgene-schema/2.1.0/

Test install from PyPI release successful:
$ cellxgene-schema validate c114c20f-1ef4-49a5-9c2e-d965787fb90c_f7c1c579-2dc0-47e2-ba19-8165c5a0e353.h5ad
Starting validation...
WARNING: This dataset cannot be converted to the .rds (Seurat v3) format.<PHONE_NUMBER> nonzero elements in matrix X exceed the limitations in the R dgCMatrix sparse matrix class (2^31 - 1 nonzero elements).
WARNING: This dataset cannot be converted to the .rds (Seurat v3) format.<PHONE_NUMBER> nonzero elements in matrix raw exceed the limitations in the R dgCMatrix sparse matrix class (2^31 - 1 nonzero elements).
Validation complete in 0:23:22.528095 with status is_valid=True

Github release for 2.1.0 created:

https://github.com/chanzuckerberg/single-cell-curation/releases/tag/v2.1.0


Allow WITH clause into intellisense sql editor

Is your feature request related to a problem? Please describe.
The auto-complete (intellisense) functionality is very useful when writing a query, I see that the WITH type tables do not appear and neither the field list, this makes it difficult to write a query using this syntax.
Describe the solution you'd like
Improve Intellisense:
1- Show in the list of tables, the temporary tables of the query with clause WITH.
2- Show the list of fields from the result of the temporary table with.
Additional context
Example of query writed to MSSQL:
WITH TMP_TABLE AS (
SELECT 1 as "number" , 'One' "description"
UNION ALL
SELECT 1 as "number" , 'One' "description"
)
SELECT TMP."number" FROM TMP_TABLE

ерфтлы ащк ыгппуыешщт

Also alias for CTE should be handled.


add support for pgpass files

This pr implements support for pgpass files
Closes #1009

Looks really good! Thanks for implementing this :smiley:

Really nice work here.

I'm going to hold off on merging this in until next is ready to accept it so it goes there with your attribution (instead of being copied in later).


riemann-proc alerts output which processes matched

means you can look at which processes matched in email/etc without having to ssh into the box.

Cool!


⚠ Bofrost.lu has degraded performance

In c0819ba, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1047 ms

Resolved: Bofrost.lu performance has improved in 222915b after 48 minutes.


fix Fix ThreadContext life cycle to manual control

Proposed changes
In the past, ThreadContext was automatically created when it was used for the first time (this was usually in the Jemalloc Hook when the first malloc memory), and was automatically destroyed when the thread exited.
Now instead of manually controlling the create and destroy of ThreadContext, it is mainly created manually when the task thread start and destroyed before the task thread end.
Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

run buildall

run buildall

run buildall


Bump helm version

Description
Changes proposed in this pull request:

Bump helm version
Run go mod tidy

Related issue(s)

Waiting for https://github.com/kyma-project/btp-manager/issues/273 to be resolved.


feat: implement @subcommand decorator

About
This Pull Request implements a subcommand
Checklist

[x] I've ran pre-commit to format and lint the change(s) made.
[x] I've checked to make sure the change(s) work on 3.8.6 and higher.
[x] This fixes/solves an Issue.

(If existent): #504

[ ] I've made this pull request for/as: (check all that apply)

[ ] Documentation
[ ] Breaking change
[x] New feature/enhancement
[ ] Bugfix

I'm closing this since I don't like my approach anymore


warning: delta is never used in function process

Godot version:
master (https://github.com/godotengine/godot/commit/5d09877da8003740928502aead0b46505495721f)
related issue: #21180
OS/device including version:
Linux
Issue description:
Do I have to ignore this warning or can I replace delta with another String that doesn't trigger the warning?
Steps to reproduce:
func _process(delta):
   pass

pylint will not complain about unused variables starting with _. Should godot do the same?
[rcorre@desktop-arch tmp]$ echo -e 'def forp(thing):\n    return 1' > test.py
[rcorre@desktop-arch tmp]$ pylint test.py -d missing-docstring
************* Module test
test.py:1:9: W0613: Unused argument 'thing' (unused-argument)

--------------------------------------------------------------------
Your code has been rated at 5.00/10 (previous run: -5.00/10, +10.00)

[rcorre@desktop-arch tmp]$ echo -e 'def forp(_thing):\n    return 1' > test.py
[rcorre@desktop-arch tmp]$ pylint test.py -d missing-docstring

-------------------------------------------------------------------
Your code has been rated at 10.00/10 (previous run: 5.00/10, +5.00)

It also respects dummy and _, though I prefer _delta as it is obvious what the variable is if it is needed in the future.

See https://github.com/godotengine/godot/pull/19993#issuecomment-412260079

I'll add the underscore prefix convention to ignore the unused variable.

@vnen Also do this for functions with names starting with underscores, so that default Godot functions don't have to be changed (and delta looks cleaner than _delta IMO).

@aaronfranke No because then there's no way to opt-in for this type warning. You can change argument names at will, but the names of those virtual functions are forced. Also _delta might not look clean, but if you're actually using the argument then you don't need the underscore.

Change your code to this:
func _process(_delta):

now my godot just crashes the game window and doesnt even give any errors what should i do

@Coder6969696
Which Godot version?
Does it also crash if just delta is used?
If it's latest master, it could crash because of using self directly. Better open a new issue with add a minimal reproduction project.


i18n(zh-cn): Update markdoc.mdx

Description (required)
Update markdoc.mdx
Related issues & labels (optional)

#7743

Heads up we got a few more updates on this page would you be up to adding those changes here as well?

Heads up we got a few more updates on this page would you be up to adding those changes here as well?

I've added these updates.

最后这一部分也翻译一下吧

最后这一部分也翻译一下吧

这个 follow 这么翻译合适吗


GDPR + Cookies Plugin Notifications Not Displaying Unless Logged into Admin Panel

Hello everyone,
I'm facing an issue with the GDPR + Cookies plugin (version 1.8.3) on my Concrete5 Core 8.5.2 website. I've enabled the notifications for GDPR and cookies, but they are not showing up on the website for regular users. Strangely, the notifications only appear when I'm logged into the admin panel.
Has anyone else experienced this issue? Any suggestions on how to resolve it would be greatly appreciated.
Thank you!

Cookie notification in the dashboard is the core feature, not from this package. I think you haven't enabled cookie notification yet.


the first value for the day is too high

I using this project since yesterday but todays first import is too high
it is 1800
In the logging I see also the v1 is 1800
What can cause this issue.
I have implemted the fixes from @vijghph
https://pvoutput.org/intraday.jsp?id=74365&sid=65959&dt=20190326

I got the same problem since 7 days ago.

Since April 19 I've got this issue too. See https://pvoutput.org/intraday.jsp?id=62026&sid=55213
I think something has changed on the GoodWe server, because I haven't changed anything.
I hope somebody has got a solution for this, as my solar array is facing west, I can see the real values only from 1PM on.

Same here, starts with 4.550kWh every day.

Same problem here, however de starting value of the day is different from day to day. Already applied the fix from vijghph but it doesn't seem to make any difference. Hopefuly someone can help to fix this issue.

same issue....

For the people how wants/needs an alternative:
https://github.com/zonoskar/Goodwe2PVoutput/

To bad I'm having the same issue.
Besides this isseu, the script works great.

Today this happened to me too... Yesterday I added the --skip-offline option. Maybe related?

I investigated:
I adapted the code to not use an average for the generated power, and now production starts at 0 kwh the next day.... I'll make a pull request for this...

Pulled the changes you made Jaap and it seems to work fine, thanks for your effort.

Hi Jaap, I modified the script and it works, thanks!
2 Question,

How to deal with two MPPT, is there a possibility to sum both MPPT?
How to use the temperature value from the inverter?

Looks like people are happy about  #PR18, so I accepted it. Thank Jaap for you effort!

This fixed it, thanks @JaapBraam !

How can I apply this fix?
I’ve tried to reinstall the package, but I received notifications of duplicate files. Then reinstalled the package with —upgrade at the end. That resulted in some errors.
Can anybody describe in easy-to-follow steps what to do?

As it's not a new release yet, you would need to build the package from source code yourself

Ok that’s a pity, in that case I will wait until a new version comes out.

Same here :)

I'll build a new release this evening (if don't forget it ;)

Build new release: https://github.com/markruys/gw2pvo/releases/tag/1.2.2

I installed the new release 3 days ago and it’s working like a charm! Thanks for the effort @JaapBraam and @markruys


Update Area Management Styling

Make the area management look like the mid-fi design - update the CSS.
Also, change the file type from .css to .module.css so that the CSS changes are not global (Read more about this issue here)
https://www.figma.com/file/O2igPzMS1fZPzjmOxlo6Mc/TLP-Wireframes?node-id=538%3A23322

/cib update-area-management-styling

Branch 49-update-area-management-styling created!


Revert cookie banner tracking

Removes the cookie banner tracking which fires when the cookie banner is hidden. This would fire an additional event on every user page view, which will build up our analytics events to hit our limit. Instead, we will be adding a custom dimension to the existing pageview event.
This essentially reverts #821.

 Improve cookie banner tracking


also check windows=* for specifying building has no windows

before/after
(building parts are all tagged windows=no)

https://www.streets.gl/#51.46842,0.00747,25.75,325.50,206.40
window=* is part of simple indoor mapping schema, and implies a single window (with a node and window=yes)
windows=* is more generic, is unused, and makes more sense.
It looks like people assumed this was the correct tag in the first place, the usage increase matches the release of streets-gl: (link)

Fixes offhand comment at end of https://github.com/StrandedKitty/streets-gl/issues/69#issuecomment-1538228725

It seems like window=yes/no can be used on entire buildings, as pointed out by Tordanik in this thread: https://community.openstreetmap.org/t/streets-gl-a-new-3d-renderer-for-osm/98594/14
On the wikipage that describes this tag (https://wiki.openstreetmap.org/wiki/Key:window) it is stated that window=no can be used on a feature if "there are no windows on this building, building:part or door".
So maybe it would make more sense to support both window and windows?

If window=no can be used with the same meaning, does it make sense to have both? 62% of windows values are added by 4 users.

ah! i didn't realise window=no could be used in that way 👍
PR now checks both, and adds a few more building types that shouldn't have windows

I don't know if that's a good idea to introduce a new tag (windows=) though, given that there's already window=. The naming does make much more sense though, windows=* suits building better.

@endim8 Ok, thank you