This relates to #134 and #151.
While efforts to improve this issue have been merged (#156), this now have introduced a regression.
On a clean installation, resources/assets/js/blocks will be fresh and empty (recently created), so attempts to cp -R the directory contents will result in the following error:
cp: cannot stat 'resources/assets/js/blocks/*': No such file or directory
A workaround to this is create the directory manually and use touch to generate an empty file:
$ mkdir -p resources/assets/js/blocks/
$ touch resources/assets/js/blocks/dummy.js
And then twill-build completes successfully.
A pure-PHP option is possible, but there is no one-liner command for recursive copy, so this might need to be researched further.
Thank you for your time and available to discuss/test any alternatives.
Cheers.
鉂わ笍 鉂わ笍 鉂わ笍
A workaround to this is create the directory manually and use touch to generate an empty file
I think this would be a bit confusing to new users. Would script also run if we would create a readme.md file instead of dummy.js? It could contain information about purpose of this folder etc. I guess this could be created by modifying artisan twill:install
A pure-PHP option is possible, but there is no one-liner command for recursive copy, so this might need to be researched further.
This is probably another reason why moving npm scripts to artisan commands would make sense. But I guess this is being worked on already, if I am not mistaken. :)
I think this would be a bit confusing to new users.
Indeed confusing. Definitely what I suggested was a quick (and dirty) workaround until a proper solution is presented. Your approach of a short readme.md sounds interesting.
Thanks for your input and notes!
Yeah, I guess using a glob pattern wasn't the best idea.
Can you please try these scripts and see if they'll work properly?
"twill-copy-blocks": "npm run twill-clean-blocks && mkdir -p resources/assets/js/blocks && mkdir -p vendor/area17/twill/frontend/js/components/blocks && cp -R resources/assets/js/blocks vendor/area17/twill/frontend/js/components/blocks/customs",
"twill-clean-blocks": "rm -rf vendor/area17/twill/frontend/js/components/blocks/customs"
Alright folks, I have something for you today :)
I worked on an Artisan based build script which should solve our npm scripts cross-OS issues (especially Windows)! I will release it later today but wanted to give you a sneak peek at the source code and output:
<?php
namespace A17\Twill\Commands;
use File;
use Illuminate\Console\Command;
use Symfony\Component\Process\Process;
class Build extends Command
{
protected $signature = 'twill:build';
protected $description = "Build Twill assets";
public function handle()
{
$progressBar = $this->output->createProgressBar(4);
$progressBar->setFormat("%current%/%max% [%bar%] %percent:3s%% %message%");
$progressBar->setMessage("Installing npm dependencies...\n\n");
$progressBar->start();
$this->npmInstall();
$progressBar->setMessage("Copying custom blocks...");
$progressBar->advance();
$this->copyBlocks();
$progressBar->setMessage("Building assets (be patient...)\n\n");
$progressBar->advance();
$this->npmBuild();
$progressBar->setMessage("Copying assets...");
$progressBar->advance();
File::copyDirectory(base_path('vendor/area17/twill/public'), public_path());
File::delete(public_path('hot'));
$progressBar->setMessage("Done.");
$progressBar->finish();
}
private function npmInstall()
{
$npmInstallProcess = new Process(['npm', 'ci'], base_path('vendor/area17/twill'));
$npmInstallProcess->setTty(true);
$npmInstallProcess->mustRun();
}
private function npmBuild()
{
$npmBuildProcess = new Process(['npm', 'run', 'prod'], base_path('vendor/area17/twill'));
$npmBuildProcess->setTty(true);
$npmBuildProcess->mustRun();
}
private function copyBlocks()
{
$localCustomBlocksPath = resource_path('assets/js/blocks');
$twillCustomBlocksPath = base_path('vendor/area17/twill/frontend/js/components/blocks/customs');
if (!File::exists($twillCustomBlocksPath)) {
File::makeDirectory($twillCustomBlocksPath);
}
File::cleanDirectory($twillCustomBlocksPath);
if (!File::exists($localCustomBlocksPath)) {
File::makeDirectory($localCustomBlocksPath);
}
File::copyDirectory($localCustomBlocksPath, $twillCustomBlocksPath);
}
}
$ php artisan twill:build
0/4 [鈻戔枒鈻戔枒鈻戔枒鈻戔枒鈻戔枒鈻戔枒鈻戔枒鈻戔枒鈻戔枒鈻戔枒鈻戔枒鈻戔枒鈻戔枒鈻戔枒] 0% Installing npm dependencies...
1/4 [鈻撯枔鈻撯枔鈻撯枔鈻撯枒鈻戔枒鈻戔枒鈻戔枒鈻戔枒鈻戔枒鈻戔枒鈻戔枒鈻戔枒鈻戔枒鈻戔枒] 25% Copying custom blocks...
2/4 [鈻撯枔鈻撯枔鈻撯枔鈻撯枔鈻撯枔鈻撯枔鈻撯枔鈻戔枒鈻戔枒鈻戔枒鈻戔枒鈻戔枒鈻戔枒鈻戔枒] 50% Building assets (be patient...)
3/4 [鈻撯枔鈻撯枔鈻撯枔鈻撯枔鈻撯枔鈻撯枔鈻撯枔鈻撯枔鈻撯枔鈻撯枔鈻撯枒鈻戔枒鈻戔枒鈻戔枒] 75% Copying assets...
4/4 [鈻撯枔鈻撯枔鈻撯枔鈻撯枔鈻撯枔鈻撯枔鈻撯枔鈻撯枔鈻撯枔鈻撯枔鈻撯枔鈻撯枔鈻撯枔鈻撯枔] 100% Done.%
cc @luislavena @yanhao-li @ferpetrelli @zipavlin @amrnn @folkevil @milewski @khyoz @nsivertsen @mediaboost

@ifox
@ifox i foresee a problem with that approach...
Usually i dev in 2 environments Mac and Win
Every single development tool runs through docker, even php i usually make a local alias to help executing them like:
this file is located at /project/root/folder/php (no extension) with the following:
docker exec -it my-php-container-name php $@
so instead of executing php artisan something i do ./php artisan something
which saves me from polluting my host machine with development tools, beside docker, and gives great flexibility swapping from projects to projects with different requirements etc...
and i have same helpers for npm, composer, mysql etc...
so when you run $this->npmInstall(); for example it will run from within the container so the node-sass, and other dependencies that is platform specific ended being built for linux, which is fine when i am on a Mac as i run ./npm run twill-watch anyways however on windows... running tasks that involves intensive IO operations, like npm install, webpack, composer install within a container is extremely slow!! even having 16gb of memory and SSD it doesn't help, it certainly has something to do with the extra virtualization layer with HyperV that docker uses on win,
so on win i actually need to run those command from the host machine... npm install.. npm run twill... however it wont run if the node-sass for example is built for linux... so now it would make my life a bit harder on win as i have no idea what would be the necessary "commands" to run without digging into the php files and understanding what it`s doing..
this problem has hit me so many times that i end up building a lib to assist in my projects: https://github.com/milewski/cross-os which works pretty well
Also forgot to mention that the php container would require node installed...
Run into the same problem. Thank you @luislavena and @ifox
Same problem on Mac. Thank you @luislavena and @ifox
However i still get: Error: not found: python (I am using laradock)
Same problem on Mac. Thank you @luislavena and @ifox
However i still get: Error: not found: python (I am using laradock)
Not sure if you were able to find a solution for this issue @freeyland but if you access your workspace container, install python and then run the npm buid command it works.
@ifox How to use that command? I dropped it into my app\Console\Commands but once I type php artisan in console to list all commands it is not showing up..
This has been addressed in 1.2.1 and the expirimental artisan based build command has been added: php artisan twill:build.
Also, a clean install now doesn't require building anymore as it directly publishes compiled assets!
Building is now only needed when creating new blocks or contributing to Twill and the issue with the empty blocks folder had been fixed as well in the npm scripts provided in the documentation.
Another improvement in 1.2.1 is the update to Laravel Mix 4 which in turn updated Sass compilation to use the Dart implementation instead of node-sass which caused a lot of trouble because of its environment dependant build.
I think we can do more to support Windows and Docker based environment but for now I'm going to close this issue as the original point has been addressed!
Most helpful comment
Alright folks, I have something for you today :)
I worked on an Artisan based build script which should solve our npm scripts cross-OS issues (especially Windows)! I will release it later today but wanted to give you a sneak peek at the source code and output:
cc @luislavena @yanhao-li @ferpetrelli @zipavlin @amrnn @folkevil @milewski @khyoz @nsivertsen @mediaboost