Hi Rasmus, Trying to write inline, so I don't miss your question.
> Why do you want the folder name to be named assets itself ? > > The folder has to have a name - "assets" seemed like the logical choice. > > Perhaps what you're really wondering is, why a single folder and not a > map like in the Aura library? > > Because it's simpler. A map would require more than a standard - it > would require at least a configuration file format specification, > and/or possible a library or interfaces. > What we followed was just an array, no other format. [ 'vendor/package/css/hello.css' => dirname(dirname(__DIR__)) . '/asset/css/test.css', 'vendor/package' => dirname(dirname(__DIR__)) . '/asset', ] > Also, because we learned from doing something similar at work, that > being able to symlink vendored asset folders into the project's public > asset folder is really useful - it enables you to run an installation > script once, and the continue to add more files to the vendor > packages, since every file in the symlinked folder becomes > automatically available. > Symlink may be easy. I was not using symbolic link and the files were served via psr-7 response though. It lacks caching and stuffs like that for now. > Another reason is that a map cannot be interpreted or resolved at > design-time, by the browser - things like source-maps of relative > paths fall apart, since the relative public URLs do not map directly > to physical files. This is perhaps the main reason we came up with > this approach - anything else has proven to be highly impractical to > work with. Having to run a build or deploy script between every change > is cumbersome. > Ya, the approaches choosen to serve the files is a bit different. You follow symlink, we followed directly looking at filesystem and reading the contents and serving as psr-7 Response . > Finally, the length or appearance of asset URLs is typically > completely irrelevant - about as irrelevant as the physical > file-system structure is to Composer packages. For the most part, no > person will ever see the URL of your CSS or JS files - wanting shorter > or neater URLs is purely vanity, it has no practical consequence. > Having a simple, predictable URL structure that prevents collissions, > is much more valuable than having pretty URLs. > I have no trouble with the length of the url. Not sure if someone else asked the same. -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscr...@googlegroups.com. To post to this group, send email to php-fig@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAESZFt%2BVK3ORC7pB-7iDd0j5-kZZ1TZ06ruoRmVzy5tswiy9Tg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
