Components with Cyclic dependency breaks production

[muralikr]

With mendel-loader@3.0.0, we are reading component files from build/server folder. In one way, it is good since we don't have to transpile these files anymore in runtime. Earlier, we were reading es6 files from full-example folder for server side rendering.

With this change, we don't seem to support cyclic dependency anymore. I have created a test commit to create this behavior inside full-example. I am able to launch this app in development mode. In production, it always throws error.

TypeError: Foo.getLogString is not a function

[muralikr]

I have investigated this issue with our application. I found why this issue surfaces only in production mode.

In Mendel V1, we were able to catch these issues in dev mode. Since we have daemon in Mendel V2 (to boost developer productivity). Now, daemon caches all modules so resolving dependencies is always smooth.

It is hard to resolve cyclic dependencies in runtime (same with other libraries), we should show a warning to developers for such cases. This will help in catching these issues very early.

[irae]

I think this can be implement in the client, specially because this is on a per bundle request. I think deamon is correct so far. Deamon job is to get a bunch of source files and do all the transforms, watching file system, etc. If the dependency is circular or not depends on bundle resolution.

I am curious tho that in development the issue does not exist. Were you able to diagnose why development works well?

[muralikr]

In production during server side rendering, mendel tries to resolve all dependencies. In mendel-loader/resolver.js file, we store incomplete module in cache. If other files request for this module before mendel internal cache gets updated, they get only incomplete module.

This doesn't happen in development mode, since daemon stores all complete modules in its cache. I am yet to fully investigate why dev works fine, please let me know if my hypothesis is wrong.

[irae]

I think it makes sense.

But on the other hand, I remember @gomezd implementing this, and there was a notion of testing to see if the request is ready. Since the middleware is async, it is possible to wait for it to be ready.

This way, during SSR, you can hold until the resolver is ready and call the code only once incomplete module is done.

We might need to expose to the middleware some sort of listener. I don't know how development middleware deals with it exactly, but I think it waits for the sync event from the daemon.