postBuild fails -- dist is empty

[brianally]

Using 0.2.7.

I have an addon that copies files from dist on postBuild. This has been working fine. Suddenly, (as in, I merely deleted a console.log() line) i'm getting the following error:

Build failed.
ENOENT, no such file or directory '/var/www/vhosts/employeronestats/client/dist/index.html'
Error: ENOENT, no such file or directory '/var/www/vhosts/employeronestats/client/dist/index.html'
    at Error (native)
    at Object.fs.statSync (evalmachine.<anonymous>:801:18)
    at Object.copySync (/var/www/vhosts/employeronestats/client/node_modules/fs-extra/lib/copy.js:74:58)
    at Class.module.exports.postBuild (/var/www/vhosts/employeronestats/client/lib/asset-delivery/index.js:11:6)
    at /var/www/vhosts/employeronestats/client/node_modules/ember-cli/lib/models/builder.js:109:34
    at Array.map (native)
    at Class.module.exports.Task.extend.processAddonBuildSteps (/var/www/vhosts/employeronestats/client/node_modules/ember-cli/lib/models/builder.js:107:43)
    at lib$rsvp$$internal$$tryCatch (/var/www/vhosts/employeronestats/client/node_modules/ember-cli/node_modules/rsvp/dist/rsvp.js:489:16)
    at lib$rsvp$$internal$$invokeCallback (/var/www/vhosts/employeronestats/client/node_modules/ember-cli/node_modules/rsvp/dist/rsvp.js:501:17)
    at lib$rsvp$$internal$$publish (/var/www/vhosts/employeronestats/client/node_modules/ember-cli/node_modules/rsvp/dist/rsvp.js:472:11)

Looking through lib/models/builder.js, in build() i see that processAddonBuildSteps, which calls the addOn, is called before processBuildResult, which copies files to dist. Has this changed recently? I can see how it could potentially work out ok, being promises. But i've noticed that, since upgrading, sometimes a build does not include changes just made, and i have to restart the server to generate a new build. Now that i'm getting this error it does seem that something is different about building in this version.

UPDATE: The order was changed May 6. I don't know how to properly link to this; apologies.

1ef8617

I can't say that i agree with the reasoning. If it's really worthwhile having a hook available after the build but before copying, then perhaps a new hook should be created. The docs for postBuild do say that it can be used as a hook for copying files. This is no longer the case.

[trabus]

I'm open to a new hook, maybe add another where postBuild used to be, and name it postProcessBuild.

@ember-cli/owners thoughts?

[brianally]

Or maybe postOutput? postResult?

For now, i've created a bash script to call ember build and then copy the files. It works, although i can no longer use the livereload goodness.

[aaruna]

@brianally You could do one other thing, which is working out for me.
The results.directory though pointing to a tmp/... folder, contains the index.html and assets, so you can copy them to wherever needed. The problem is, sometimes, (esp in Prod build), the index.html in results.directory is a symlink. So to handle all these cases, this snippet seems to be working for me

indexContents = fs.readFileSync(results.directory + '/' + indexFile, {encoding: 'utf-8'});
fs.writeFile(indexFile, indexContents, function(err) {
    if (err) {
        console.error('Error writing index.html', err);
    }
});

[brianally]

@aaruna Thanks for the tip. It looks like that could work, although it seems somehow wrong to be copying from tmp. I think it would be better to access the final build (in dist) rather than one of potentially several copies under tmp.

I understand the motivation for having a hook for before the files are moved, but do not agree with the decision to remove the actual "post build" hook.

[aaruna]

@brianally I agree with you. The issue exists. What I mentioned, was a workaround till the actual "post build" hook is introduced.

[btecu]

This is a blocker for many who have ember as part of another project. Since builds outside the dist folder are not working (#3284), the other option was to write an addon and use the post-build hook. I see this doesn't work anymore either.

[brianally]

@aaruna understood that it's a workaround. I meant only that it's not a great permanent solution, should anyone else suggest that it is. I should have been clearer. Thanks again for the symlink tip. I hadn't thought about that.