generator-chisel

generator-chisel copied to clipboard

We would like to have simple way to quickly setup new users or people not familiar with Chisel.

We need some kind of cross platform simple solution that would set up Apache, MySQL etc. automatically. Docker and Vagrant are options we are considering currently but any other ideas are welcome.

Vagrant is pretty heavyweight and slow, isn't it? So my first choice would be Docker. Still wondering how fast it would be to set up a project comparing to when you have own Apache, MySQL already running. Or do we keep the current setup too?

@luboskmetko on some machines (depending on things installed and configured) setting up everything so it works correctly with chisel takes more than a day.

cc: @arturkot

Hi everyone,

I started playing around with Docker few days ago. Here's what I have: https://github.com/arturkot/docker-chisel Currently it's Debian with preinstalled node, yarn, yo, and chisel. It can create a project in app/ folder. WP isn't supported at the moment. We'd have to figure out how to wire Chisel container with whole Apache and Mysql setup to run the CMS. Here's an interesting setup https://x-team.com/blog/keep-your-local-machine-clean-with-docker-2/ I found thanks to this article: https://x-team.com/blog/keep-your-local-machine-clean-with-docker-2/

It's more like a scratch (I was playing around) than the real thing. Still, I think it's worth investing time into figuring out how Chisel could work with (within?) Docker. It has a great potential to make work with Chisel and WP much easier and less error prone.

Thanks, Artur, I've tried it and got the following error:

Creating dockerchisel_chisel_1 ... error

ERROR: for dockerchisel_chisel_1  Cannot create container for service chisel: invalid bind mount spec "C:\\docker-chisel\\app:/app:rw": invalid volume specification: 'C:\docker-chisel\app:/app:rw'

ERROR: for chisel  Cannot create container for service chisel: invalid bind mount spec "C:\\docker-chisel\\app:/app:rw": invalid volume specification: 'C:\docker-chisel\app:/app:rw'
ERROR: Encountered errors while bringing up the project.

Then when I try run yo chisel got this:

PS C:\docker-chisel> yo chisel
path.js:7
    throw new TypeError('Path must be a string. Received ' + inspect(path));
    ^

TypeError: Path must be a string. Received undefined
    at assertPath (path.js:7:11)
    at Object.join (path.js:468:7)
    at Environment.resolver.getNpmPaths (C:\Users\Lubos\AppData\Roaming\npm\node_modules\yo\node_modules\yeoman-environment\lib\resolver.js:133:21)
    at Environment.resolver.lookup (C:\Users\Lubos\AppData\Roaming\npm\node_modules\yo\node_modules\yeoman-environment\lib\resolver.js:33:56)
    at init (C:\Users\Lubos\AppData\Roaming\npm\node_modules\yo\lib\cli.js:117:7)
    at pre (C:\Users\Lubos\AppData\Roaming\npm\node_modules\yo\lib\cli.js:76:3)
    at Object.<anonymous> (C:\Users\Lubos\AppData\Roaming\npm\node_modules\yo\lib\cli.js:205:3)
    at Module._compile (module.js:570:32)
    at Object.Module._extensions..js (module.js:579:10)
    at Module.load (module.js:487:32)
PS C:\docker-chisel>

I was able to run this https://docs.docker.com/compose/wordpress/ though. Creating that image was quite fast, around 2 minutes. In general it feels quite fast in what it does.

One potential problem we would have to solve is accessing the WP instance via domain name because now you can access it via my-project-name.dev too and you get revision and minified files there, but not sure how this would work with Docker.

I got quite intrigued by the idea, but went on a slightly different route and tried running existing chisel project inside docker (apache & mysql only), you can try that out too:

1. Make sure you don't have wp-config-local.php in wp directory
2. Run in the project root directory:

curl https://gitlab.com/jakub300/chisel-docker/raw/master/docker-compose.yml -o docker-compose.yml
docker-compose up

3. Go to http://localhost:8099/

Regarding your problem you may try setting COMPOSE_CONVERT_WINDOWS_PATHS environment variable, see: https://docs.docker.com/compose/reference/envvars/#compose_convert_windows_paths.

I wonder what exactly is our goal, which dependencies we are trying to get rid of (php, mysql, apache?) and which can stay (node?)?

Hey @jakub300 ,

I think the goal is twofold:

1. To provide OS independent (as far as possible) environment to setup Chisel effortlessly. Not so far ago I participated in workshop with Marcin Krzeminski. It's turned out that about half of the time was spent configuring local env to be able to run Chisel. Node, NPM, php, MySQL – all of them. Random problems on random OSes. Someone got node setup quickly but failed with SQL on Linux. Somebody else has got everything right but the some paths were lacking to use NPM packages. So on and so forth. On one hand, small problems and relatively easy to resolve, but on the other hand... It just takes valuable time. For less experienced people it's a show stopper. Of course you could point out – hey, you need to setup Docker to make everything work and that's impossible for some people as well. ;)

2. To simply run existing projects (as you've shown above). That's valuable as well. Can really make WP setup much more pleasant experience. Not to mention benefits of the same local environment. Less possible to stumble upon "but it works on my machine" bugs.

Theoretically it would be possible to setup everything within one container (Linux with preinstalled all deps and preconfigured setup). Not sure if it's a good practice or anti pattern, though? Perhaps it would be better to compose few containers and glue the together?

Cheers,

Artur

PS.

Thanks for putting up this docker compose setup. 👍

Hey @arturkot, Thanks for comprehensive writeup on the reasons we want to do that but I'm also interested in more technical aspect. In other words, what dependencies/requirements are acceptable on the developer's machine and what should be entirely in the container(s)? I gave examples in the previous message.

Apache, PHP, MySQL would be my first choice to put in containers, but wondering why we cannot do the same with Node and other dependencies?

@jakub300 @luboskmetko

I guess it really depends on a developer. From my point of view the whole LAMP setup would go first as I don't have problems with Node whatsoever (similar with Ruby btw. – easy to manage with RVM). Now, it can be the opposite for more WP focused developers. From what I've noticed many of them had some LAMP server installed but Node was installed using (exe) installer. Sounds good? Not when you need to switch Node/NPM version for a specific project. ;) It does happen!

Referring to my previous points:

1. This one would require full setup. Node, Yarn, Yo, PHP, MySql, etc. – all is there ready to use. This would effectively be like fully pre-configured virtual machine ready to use with Chisel.

2. Apache, PHP, MySQL running the project on localhost would suffice.

PS.

Recently I had a chance to configure setup for FE Chisel project on Windows 10 with Chocolatey. I must admit it went really smooth! Installed Yarn and NVM in no time. 👍Just typing choco install [package name] feels a bit funny. ;)

Hi,

from my point of view the docker image should contain the whole thing:

• web server + DB server
• chisel + all dependencies (NPM, Yarn, yo, etc)

I boot up the machine and simply run: yo chisel

As of the vhost, I think there is no need to think about it. We can server standard WP on http://localhost:8888 (for example) and Gulp task could proxy to it. We don't need the *.dev in that case. It's just for local development. No need to use *.dev in that case, isn't it?

Would this be our standard way of development in the future or just an alternative?

Thanks, @marcinkrzeminski

I think it should be standard if it works reliably and fast.

Regarding *.dev vs. localhost - the use case for it is described here https://github.com/xfiveco/generator-chisel#2-develop-1, so .dev uses revisioned/minified files while localhost doesn't. The reason for that was performance, the question is if we still need it.

@marcinkrzeminski .dev is hardcoded in few places, but that's more of a bug than intentional decision (see #189). @luboskmetko If you run apache on http://localhost:8888 and tell gulp to proxy to it (as Marcin suggested) than http://localhost:8888 will have revisioned files and Gulp not revisioned.

@jakub300 makes sense, I didn't realized there would Browsersync version running at http://localhost:3000/ yet

@jakub300 this is exactly what I meant :) We treat localhost:WHATEVAPORT as our "*.dev" which should work with the revisioned files without any problems, it's just a host. It shouldn't be a big problem to make it dynamic I guess. I can help you with that if you guide me a little bit.

I created a repo that shows how to configure and setup Chisel with Lando. It is currently a bit of a quirky setup & install, but it works. I would be curious to know if any of you have any issues getting it working. You can check it out here:

https://github.com/robertguss/Lando-Chisel

I am going to try and clean this up so that Lando will include Yeoman, Node etc so the user won't need to have any dependencies installed locally on their machines. Ideally the containers should have everything you need to get going.

Would love your thoughts/feedback.

@robertguss thanks, appreciate your work on it. I'd like to try but I'm on Windows Home edition and Lando requires Windows 10 Professional with Hyper-V enabled. Would be nice if someone else could try this, @jakub300 or @arturkot?

We need to consider how to approach this. The problem is that many developers for whom we'd like to make the setup easier, could also be on Windows Home which complicates usage of Docker and related tools. On Windows Home only legacy Docker Toolbox is available and its installation and running is not always straightforward (I've just spent a half an hour to make it run again after update).

@luboskmetko my pleasure. Thank you guys for such an awesome project.

I didn't realize the limitations of Lando or Docker in regards to Windows Home edition. I think that this limitation just goes to show that there really isn't a one stop shop, single solution, that will work on any and every machine and OS. So maybe there needs to be a couple variations of tools/environments for various OS's.

I think it would be helpful to know which platforms you would like to target specifically so that we can figure out the best approach to write tooling for those specific platforms. So maybe we have a docker build and a custom Vagrant box? It is possible to create a custom Vagrant box that has all the tools and dependencies built in, and I would be more than happy to try and tackle this if you would like. A Vagrant box I really like and have used in the past is: https://box.scotch.io/

I have the pro version which comes with their build scripts, so I can just customize that and create a custom Vagrant box specifically for Chisel if you want. Just let me know how I can help.

@robertguss thank you for your willingness to help with the project. You're right that we would need more alternatives to the tool's installation.

Regarding the platforms, we aim on all common platforms developers can use for WP development, so macOS, Linux and Windows Home/Pro editions. It would be great if we can still create an environment which would work on Windows Home too. If not, those users would have to use current setup with WAMP/XAMPP.

Vagrant box sounds good, but I'm just trying it after a few years and getting very slow download speed on vagrant up on default Scotch Box. Currently it's downloading virtualbox and looks it will take 3 hours. I've noticed other users reported slow speeds too. Is there a way how to address it?

@luboskmetko I have created a custom Vagrant Box prototype for Chisel. You can find it here: https://github.com/robertguss/Vagrant-Chisel

The readme should have all the details you need to get up and running, but please let me know of any issues.

FYI this is my first time building a custom Vagrant Box, so I am learning a lot of new things as I build this out. You should download virtual box and vagrant manually from their respective websites as this should increase download speeds significantly, make sure you are also using the latest versions of each.

Typically when users report slow speeds with Vagrant, it has to do with the file sharing/writing between the local host machine and the VM and keeping all of the files in sync. I have modified the vagrant file to do this as quickly as possible with: config.vm.synced_folder ".", "/var/www", :nfs => true, :mount_options => ["actimeo=1"]

In my own testing of this, browsersync refreshes just as quickly on my local machine as it does inside of the VM. Granted mileage might vary depending on the user's computer's resources.

This should help speed things up quite a bit, at least that is what I have found from my research thus far. The trickiest part was getting browsersync to work, and I have instructions in the readme to get that up and running. However, I currently am unable to get browsersync to work externally so I can't access browsersync say from my phone or any other device on my wifi, just my computer. I am working on this though.

Also note that when you run vagrant up, this is going to take some time as you are building the Box from scratch and the script in there is running all of the installs for php, apache, node etc. Once this box is finalized I believe I can package it up as an actual box and that way each user won't have to build the box on their machines. They can just download and vagrant up, but since this is very much a work in progress I don't want to do that now.

Let me know how it works for you and your thoughts/feedback.

@robertguss thanks, that's a great start. Personally, I've got stuck here:

? Enter the database host: 127.0.0.1
? Enter the database port: 3306
? Enter the database name: chiselbox
? Enter the database user: root
? Enter the database password: [hidden]
Error when testing database connection:
Error: ER_ACCESS_DENIED_ERROR: Access denied for user 'root'@'localhost' (using password: YES)

I did ssh to vagrant and could log to mysql with root:root combination. Also chiselbox db is there and myslqcheck works. Not sure what the problem could be, maybe @jakub300 has some idea?

But I was able to setup and run a front-end project.

Then there were some other minor Windows issues when setting up Vagrant, but those could be solved by documenting differences for Windows:

I had to do:

vagrant plugin install vagrant-vbguest
vagrant plugin install vagrant-winnfsd

and just then:

vagrant up

Building the box took a while, but I understand this can be optimized by packing up the box. We could remove things like grunt, bower from install.

Then on Windows there was just /public folder not /var/www/public

@luboskmetko I am not sure why you had an issue with the Chisel install connecting to the DB, especially if you were able to log into mysql with root:root. That is peculiar to say the least.

I attempted to run WIndows 10 Home Edition as a VM on my mac and run this Vagrant Box, but it's just too much of a resource hog have 3 virtual machines running inside of one another.

@robertguss yes, I'm on Windows 10 Home Edition but eventually made it work :)

I've got confused and didn't realize I need to run vagrant ssh to connect to the box after running vagrant up and just then the remaining commands. So the MySQL connection error was irrelevant as it was caused by connecting to my local db.

Then I've encountered one more issue:

vagrant@ChiselBox:/var/www/public$ npm run dev

> [email protected] dev /var/www/public
> gulp

[14:19:06] Using gulpfile /var/www/public/gulpfile.js
[14:19:06] Starting 'styles-watch'...
[14:19:07] 'styles-watch' errored after 930 ms
[14:19:07] Error: ENOENT: no such file or directory, scandir '/var/www/public/node_modules/node-sass/vendor'
    at Object.fs.readdirSync (fs.js:904:18)
    at Object.getInstalledBinaries (/var/www/public/node_modules/node-sass/lib/extensions.js:128:13)
    at foundBinariesList (/var/www/public/node_modules/node-sass/lib/errors.js:20:15)
    at foundBinaries (/var/www/public/node_modules/node-sass/lib/errors.js:15:5)
    at Object.module.exports.missingBinary (/var/www/public/node_modules/node-sass/lib/errors.js:45:5)
    at module.exports (/var/www/public/node_modules/node-sass/lib/binding.js:15:30)
    at Object.<anonymous> (/var/www/public/node_modules/node-sass/lib/index.js:14:35)
    at Module._compile (module.js:643:30)
    at Object.Module._extensions..js (module.js:654:10)
    at Module.load (module.js:556:32)
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] dev: `gulp`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the [email protected] dev script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/vagrant/.npm/_logs/2018-03-15T14_19_07_163Z-debug.log

Managed to solve it with:

npm rebuild node-sass --no-bin-links

Since then it works like you described and looks quite promising.

A few additional thoughts:

• from UX perspective it would be good if we somehow manage to detect in which context Chisel setup runs and skip the prompts for which we can use default values, eg. DB name/user/password on Vagrant setup, update Browsersync config, etc.
• if this cannot be done automatically, then we probably need to add a new prompt to Chisel with the setup type (LAMP,Vagrant,...)

@luboskmetko glad to hear you got it working. Sorry for the confusion about ssh'ing into Vagrant, I completely forgot to specify that in the instructions. I have since updated the readme.

My guess is that the issue with node-sass rebuild, has to do with the version of node inside of the VM and the version in Chisel's package.json. We can of course install a specific version of Node to prevent this inside of the VM, just let me know if there is a specific version you would like to use. Currently the VM is using Node version: 8.9.4

I agree with your additional thoughts, although I think this would have to be done via a prompt in the Chisel generator

@luboskmetko I managed to get browsersync to work externally on phones, iPad's etc. I have updated the readme with instructions. Basically, the only way this will work is if we do not run npm run dev or yarn dev while ssh'd into Vagrant. We need to run this on our local machines and browsersync will work. I don't think this will really be much of an issue as the dev will simply need to have node installed on their local machines.

@robertguss thanks for the update. Nice that you have made Browsersync to work externally, I think it shouldn't be a problem to run it on local machine with Node installed if needed.

Regarding Node version, Chisel should run on 6, 7, 8 (https://travis-ci.org/xfiveco/generator-chisel) so wondering if that's related. I've noticed there were some issues reported in gulp-sass recently and we need to bump up packages version in Chisel projects anyway. So we can get back to this later and see if it persists.

@luboskmetko sounds good. Just let me know when that time comes and I will update accordingly.

Hi all, @luboskmetko,

I had some time yesterday and finished prototype for the docker implementation. You can try this.

1. Create empty directory for the project end enter it
2. Download docker-compose file, for example using wget

wget https://github.com/jakub300/generator-chisel/raw/docker/docker/wp/docker-compose.yml

3. Run docker-compose up and wait for images to download and start. MySQL initialisation may take a minute or two.
4. In different terminal run docker-compose exec chisel create. It should run standard chisel project scaffolding.
5. After scaffolding commands docker-compose exec chisel dev, docker-compose exec chisel build can be used. When running dev server it should be available on port 3000 of localhost or dockers ip address in case of docker toolbox.