0
votes

I have faced a really strange issue with vue-cli on one of my projects. I have never seen similar behavior on other Vue-cli setups.

I have multipage app, which I have configured to produce multiple apps via vue.config.js “pages” property. Each app is compiled as an single app-build. Those apps have been working, but sometime ago I faced really strange issue where one of the apps stopped initializing at all. CLI Compiler/Watcher didn’t produce any errors, nor did Chrome show anything on the console.

I tried removing parts of the code to find out if something I wrote to logic had broken it, and finally found that if anything was introduced to one of the components style-tags it broke the initialization of that build / app.js . Compiler did produce compiled build, but for some reason this application simply didn’t initialize at all. Even console.logs within that main.js -file didn’t produce anything to console, but browser had loaded it up (made sure it wasn't cache issue). I was unable to figure out the cause, so I simply removed those style-tags.

Today I faced the same issue again, but this time it comes from mixin-file, which has following lines:

    getCustomerCard(filters) {
        return window.$.post(window.vm.url.getCustomerCard, filters).then(result => { return JSON.parse(result) });
    },
    getCustomerCards(filters) {
        return window.$.post(window.vm.url.getCustomerCard, filters).then(result => { return JSON.parse(result) });
    },
    getWasteEvents(filters) {
        return window.$.post(window.vm.url.getUserWasteEvents, filters).then(wasteEvents => { return JSON.parse(wasteEvents) });
    },

The problem is within "getCustomerCards"-method, it breaks the app initialization even if it isn’t even used anywhere. By removing it the recompiled build initializes ok. I have tried following lines inside this fuction, and all these break the app initialization:

    return window.$.post(window.vm.url.getCustomerCard, filters);
    return window.$.post("window.vm.url.getCustomerCard", filters);
    return window.$.post("window.vm.url.getCustomerCard");
    return window.$.post("wiabcndow.vm.url.getCustomerCard");
    return window.$.post("windowdas.vmbfda.urasl.gesttyrCusfdstomerCsard");
    return window.$.post("(window.vm.url");

On the other hand, this doesn’t break the initialization:

    return window.$.post("wifdsn/vmbfda");

Even more baffling is that simply copying the content of the getCustomerCard to getCustomerCards breaks the initialization.

I have never befored seen this kind of behaviour, so I’m wondering if it’s possible that Babel is breaking build for some reason? Just to repeat my self: I do not see any errors anywhere, not in compilation, neither in browser.

Even more strange: The application which breaks /isn't initializing doesn’t even use this mixin at all! Mixin is used by other application / main.js, so this application shouldn’t even be broken! I’m just so baffled and haven’t been able to figure what could be the issue.

Edit:

Something I noticed… this also breaks the initialization:

getCustomerCards(filters) {
    return window.$.post("window.vm.url", filters);
},

…but this doesn’t:

getCustomerCards() {
    return window.$.post("window.vm.url");
},

I’m suspecting there has to be some strange silent error on compilation stack or something.

First bumped to this issue on Vue-Cli 4.3.1. Upgraded to latest Vue-Cli 4.4.4, but problem persists.

Edit #2: I also double checked that when application doesn’t initialize it does still have my “console.log(‘yeah’)” within the compiled js-file. This console.log was added to main.js , right after import-lines, before Vue-component is introduced and mounted (“new Vue…”) . Basically compiled build doesn’t seem to run anything from that main.js when the build is silently “broken”. Can’t just figure out what could cause the initialization to break such a way…

1
You can place breakpoints on all window.$.post calls - then create a list of all locations from which these are being called - and then also put breakpoints on these locations. You will get an idea about the call-flow during the initialization.IVO GELOV
Sure, but the problem is more devish than that: not a single one those posts get ever called, because the app doesn't initialize at all! If the name of the app is "customer-cards" and build is "customer-cards-app.js", that single file gets loaded by browser (checked & no cache issues here, because I added few key lines which I could search for from loaded source), but after that -- nothing: No error, no initialization, just empty screen. After making minor modifications to breaking row (as described) application boots up without issues.Janne
Can you compare the 2 versions of the same JS file - one version when it works and the other version when it does not work ? Perhaps you can spot what is the difference that actually breaks the initialization ?IVO GELOV
That's what I'v been thinking about as well. Compiled files seem to be quite big, so I would probably have to try to limit the amount of plugins and components compiled.Janne
You can first try to pretty-print the minified code before trying to compare - should be easier for comparison.IVO GELOV

1 Answers

0
votes

I finally resolved this. I cannot give explanation on why those certain lines seemed to work differently and there might be multiple different problems occurring at the same time, but at-least one issue was this:

Basically I stumbled upon this problem once again and this time problem was very similar: Two apps, one shared component, build breaks / doesn't initialize without errors. By modifying the code certain ways (just as in original post) I was able to get the app to work, and bit later with different mods it once again stopped working. This really threw me off!

I compared working and broken version of source code and noticed that when the shared component was broken it didn't exist at all in the app.js (such as "customer.js" or "booking.js"). Both working and broken files were identical from the top part, so I compared 'em side by side and noticed this difference:

/******/    deferredModules.push([2,"chunk-vendors"]);
vs
/******/    deferredModules.push([2,"chunk-vendors", "chunk-common"]);

By Googling I discovered what I was suspecting: Common components were separated to chunk-common.js -file. Apparently in some conditions this didn't occur (thus modifications inside component source either lead to creation of chunk-common or kept the code within the built app.js). Unfortunately when the application didn't contain necessary files (as they were not imported within HTML-file before creating Vue-instance) it simply silently failed without errors. Really frustrating.

By introducing chunk-common.js before booting up the Vue everything begun to work as intended. I had not collided with this feature on SPA, as SPA doesn't have multiple entrypoints which would be built to multiple app-builds.

Hopefully this will help someone with the same issue.