Missing "assets/dist" folder in theme's zip file created by "stencil bundle"

[jbruni]

Expected behavior

The assets/dist folder should be included in the theme's zip file created by stencil bundle.

Actual behavior

The assets/dist folder is not included in the theme's zip file created by stencil bundle.

stencil-cli starts creating the zip file output before the assets/dist folder has been created by Webpack.

I've found this issue also reported at the following places:

• https://stackoverflow.com/questions/45110778/bigcommerce-stencil-bundle-issue-assets-dist-folder-is-missing
• stencil bundle error for stencil cli version 1.12.2 #325 (comment)
• https://forum.bigcommerce.com/s/question/0D51B00003u0zi3SAA/cdn-links-are-wrong-after-pushing-theme-to-store
• https://forum.bigcommerce.com/s/question/0D51B00003ojPqCSAU/stencil-bundle-error-stencil-cli-version-1122
• https://stackoverflow.com/questions/40004709/bigcommerce-stencil-typeerror-window-stencilbootstrap-is-not-a-function/51973523

Steps to reproduce behavior

I'm currently doing maintenance for several BigCommerce stores, using stencil-cli and a number of Cornerstone-based themes. Having worked with several stores, this is the first time I'm seeing this issue.

Update

Since April, when this issue has been opened by me here, it has been hitting us all the time. The number of BigCommerce store projects, and our team of developers has grown, and everyone, sooner or later, is getting affected by this problem. Right now (August 22) I am revisiting this issue because a developer from our team has uploaded and applied a bundled theme to a sandbox store, and the uploaded theme is broken, due to this issue...

[jbruni]

Ok. Ok. I found what is going on. The issue is not related to how long Webpack takes to do its work. Forget it. Wipe it.

The issue is related to how long the forked stencil.conf.js process takes to be "ready".

I managed to workaround the issue in two distinct ways.

---

1. Increase timeout time.

At lib/build-config.js, line 76, we have a short 1 second timeout for the prodWorker function to call its callback function: https://github.com/bigcommerce/stencil-cli/blob/master/lib/build-config.js#L76

I'm not very sure what problem this "timeout" is trying to solve. I can understand the usage of Lodash's once to avoid calling the callback twice. We can see that the callback can be called with three possible arguments: none, "noworker" or "timeout".

Unfortunately, the callback function passed at prodWorker caller code snippet does NOTHING with this argument. We could have some output message telling us about the "timeout" or "noworker" condition. The caller code snippet is at stencil-bundle.js, line 64: https://github.com/bigcommerce/stencil-cli/blob/master/lib/stencil-bundle.js#L64-L67

Anyway, the first workaround which gave me the assets/dist folder again in the bundled theme was simply enlarging the timeout amount. I changed it to five seconds, so lib/build-config.js, line 76, became:

    const timeout = setTimeout(() => callback('timeout'), 5000);

This worked. But it required changing stencil-cli code. Thus, I've used the second workaround, described below.

---

2. Make theme's stencil.conf.js be ready faster.

Once I understood what was going on, this was pretty easy to achieve, making minimal changes to the current default Cornerstone's stencil.conf.js.

I removed these two lines from the top of the file:

var webpack = require('webpack');
var webpackConfig = require('./webpack.conf.js');

And copied them as the initial lines of development and production functions, where these variables are used.

So, this way stencil.conf.js forked process is able to quickly send the "ready" message. It does not need to spend the time requiring webpack and ./webpack.conf.js. This will only happen later in the flow.

---

These two workarounds were able to bring back assets/dist into stencil bundle zip file for me. I'm actually using the second one, because it would not be feasible to change stencil-cli my team-mates are using.

In my opinion, this "timeout" approach is flawed, because it allows the zipping to begin before Webpack has completed its work. The "production" callback is called before the bundling has finished. If the "timeout" approach is really necessary, I'd do two things:

• Increase the timeout period.
• Output a message informing about the "timeout" on the "build config process" being "ready".

Thanks!

[jbruni]

@takuya4415 - This answers "why it stopped making assets/dist folder"

[CurtisWist]

Thanks for the workaround. I’ve been having this issue too. Works correctly like, 1/20 times. I’ve taken to manually copying the dist directory into the zip as well.

[karen-white]

Thanks for reporting this and writing up your workaround @jbruni . Could you confirm which OS you're working with?

[jbruni]

@karen-white - I use Linux (Lubuntu) guest in Virtual Box for development (both Windows 10 and MacOS High Sierra as host systems).

[karen-white]

@jbruni Our team has opened an internal ticket for this. I'll share this conversation on the ticket to give our team your additional context and workaround.

[bobmurdoch]

Also experiencing this issue on MacOS. Unlike the original post, I don't have a great deal of custom JS, working with a fresh copy of cornerstone.

[jbruni]

@minutiae - The issue is not related to how long Webpack takes to do its work. I was wrong at the original post, but find out what was going on and posted the details in the second post.

I have updated the original post, removing my wrong assumption.

[creativewhs]

This issue just started for me after stencil version 2.1.0

[CurtisWist]

Not sure if I should open another ticket for this or not, but they seem related.

When trying to bundle, I constantly get the following error:
Error: ENOENT: no such file or directory, open 'C:\Development\Koan\man-made-theme\assets\dist\theme-bundle.chunk.0.js'

I have to alternate between stencil start (to generate the /dist directory) and stencil bundle at least 15-20 times before it finally builds 'successfully', then manually copy over the missing /dist into the zip.

[jeremysimmons]

Ran into this too. Patching stencil.conf.js worked for me.

Microsoft Windows [Version 10.0.16299.64]
stencil-cli 1.15.1
node 6.14.2 x64

[magedesigner]

CurtisWist

I have to alternate between stencil start (to generate the /dist directory) and stencil bundle at least 15-20 times before it finally builds 'successfully', then manually copy over the missing /dist into the zip.

its working fine for me very nice solution good thanks lot .....

[jbruni]

@karen-white - Tired of waiting, and motivated by appearing at latest BigCommerce Town Hall among top 3 Cornerstone contributors... I've submitted PR #409 with the most simple workaround for this issue. It shall prevent the issue to happen for the majority of cases, if not all.

If only @mcampa and/or @mjschock were around... Maybe they, as the original code authors, could help providing a more robust fix...

[karen-white]

Nice work @jbruni ! Thanks for your help squashing this bug. We'll prioritize getting your PR reviewed asap.

[jeremysimmons]

@jbruni does https://github.com/bigcommerce/cornerstone actually accept pull-requests?!
maybe the community should just fork the project.

[jbruni]

@jeremysimmons - Hmmm... I didn't think on submitting the stencil.conf.js workaround there... Because, after all, this is a stencil-cli issue. But it sounds like a very good suggestion! I will do it.

stencil-cli releases are rare. Cornerstone releases happen frequently.

[jbruni]

@karen-white - FYI, found another report of this bug (I've added to the list in this issue's description):

https://stackoverflow.com/questions/40004709/bigcommerce-stencil-typeerror-window-stencilbootstrap-is-not-a-function/51973523

If you look at the comments to the question, you'll see more people saying it is also happening with them...

window.stencilBootstrap is not a function is the error which appears in the browser's console log, when the assets/dist folder is missing in the bundle...

[jbruni]

@karen-white - That was really "asap"... already merged! 👍

@jeremysimmons - And it looks like Cornerstone PR will also be merged. So quick!

We are used to complain... but we shall also recognize when there are reasons to praise.

[jeremysimmons]

@jbruni I'm all for there being reasons to praise. Thanks for the reminder to look for the good in the world.

[mattolson]

For everyone waiting on this bug, I apologize. We will do better in the future of watching this space for bug reports and acting more quickly on them. See #413 for the fix, which will be released in version 1.15.2.

And to @jbruni, thank you for the detailed write up, that made it easy to track down and fix this.

[mattolson]

Fixed in 1.15.2

[hsbanga]

Not fixed still showing the error