Why two locations to develop themes?

[derekclayton]

First, loving the new architecture including the use of Composer!

Why two ways to develop themes? We want to use the Composer method via "vendor" folder. But the documentation and boards indicate to develop them within the pug frontend path? Should not everything be via composer packages?

With the additional problem of the static files not displaying when in developer mode if the theme is within the vendor folder. Just how does Magento 2 determine where to find these files when in this mode?

Signed, confused as to your intent and how it is applied.

[akent99]

Here are some key directories to try and clarify their roles:

• app/design is where to locally develop a theme to have it picked up during development.
• vendor is where things go if you get a "released" package from somewhere (Marketplace, or internally) - Composer downloads into this area.
• pub/static is where files are *generated* from the theme. These are the files the web browser downloads. All fallback rules, theme inheritance, etc is all resolved by this stage.

So if using Less for CSS management, the source files live over in the theme area (app/design or vendor) and are compiled into CSS under pub/static.

Now there is a mode called "client side less compilation". There are debates over whether this feature is worthwhile to keep long term or not. For it to work however, the Less files must also be copied/symlinked under pub/static. That is so the browser can access the Less files and do the compilation.

When using Grunt/Gulp (faster than the built in tool chain), it is more efficient to do so under pub/static. However, the "magento dev:theme-source:deploy" command creates symlinks (when it can) back to the app/design or vendor directory master files. So editing an existing file in pub/static is the same as editing the file under app/design. If however you create a new Less file, you *must* create it under app/design or else it may be deleted the next time you wipe a cache.

Regarding themes not being spotted when located under the vendor directory, i suspect there is something wrong with your theme files. The Luma and Blank themes for example both sit under vendor for me, and work fine. It might be something more like you need to do a "magento setup:upgrade" or something to cause the autoloader.php file to be regeneated. I don't recall how that works, but I know it does (because I use it almost daily).

You might also find http://alankent.me/gsd interesting - shameless plug, I am trying to complete a book on themes in my spare time. Yes, that means it is going really slowly! But that is the Docker image I am personally using for the exercises in the book.

[doug_nsixty]

Is there a direct link to your docker image? I'm interested to see how you have things configured. It may shed light on some issues I'm having.

[doug_nsixty]

Ah. Never mind. Found it. https://hub.docker.com/r/alankent/gsd/

I was hoping for some nginx insight. Thanks for putting it up, anyway. 

[derekclayton]

Just to clarify, developing a theme within app or vendor should work equally well? Our preference is to stick to the composer path using vendor.

The same should apply to developing custom code.

[derekclayton]

And a quick question...

When I run magento deploy:mode:set developer from the CLI, using any theme (including the stock Luma) we no longer see any of the statics. IE images, CSS, etc... all get 404's.  Could you explain why this is and what we are missing? Note that running magento setup:static-content:deploy does fix this.

[akent99]

Some people have talked about developing under vendor. If you use a GIT URL for the package for example, I believe it does a git checkout, so you can edit there and commit changes back to the repository. Personally I do not recommend using 'vendor' for personal development for conceptual reasons - it is the place Composer puts things you should not modify. It is "third party libraries" (including your own) that you just want to use. So conceptually if you are the author, it makes more sense your official content not going there. It also means you can .gitignore the whole vendor directory. I leave that directory to Composer to manage in any way it sees fit. Does that mean it won't work? No. It just means if you ask my personal opinion I do not recommend it. But we try to keep the platform open so people can work as they prefer.

A less ivory tower view is how are you going to do source code management? As a principle, you should only put into GIT code that is yours and you change. So how are you going to use GIT if you mix other people's code that you don't want in your git repo with your own code that you *do* want in the git repo.

[akent99]

Regarding developer mode, could you be more precise? What does "when we access any of the statics" mean. A common misconfiguration with Apache is to not have URL rewrites enabled. (Or file permissions are not correct.) In developer mode, when you fetch a URL from the pub/static directory and the file does not exist, the .htaccess file redirects the request to a static.php script. This generates the file, writes it to pub/static, then returns the file. We then cache the file for speed.

[derekclayton]

Using nginx with the nginx sample config within the repo. Rewrites enabled.

We are not seeing the statics on the front-end - 404. So something is going wrong with the rewrite, the static.php or the writing of the file. But this gives us the missing piece - the re-direct to static.php.

This file it writes is a symlink or a copy?

[derekclayton]

Understood.  Personally I love the idea of having all our code within one folder - "vendor/<company>" or otherwise. Having each as a composer package on top of that is a huge plus. Everything else can be git ignored.