Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Assetic <3 Grunt, Require.JS, Almond... #529

Open
guilhermeblanco opened this issue Nov 25, 2013 · 24 comments
Open

Assetic <3 Grunt, Require.JS, Almond... #529

guilhermeblanco opened this issue Nov 25, 2013 · 24 comments

Comments

@guilhermeblanco
Copy link

@guilhermeblanco guilhermeblanco commented Nov 25, 2013

It seems Assetic needs some love with these tools. =)
So far the only way I could get to have Almond and/or Require.JS working is by hacking HearsayRequireJSBundle ( https://github.com/hearsayit/HearsayRequireJSBundle ).

@kriswallsmith
Copy link
Owner

@kriswallsmith kriswallsmith commented Nov 25, 2013

I would love to see better support around these tools too. Can you be more specific about the role you would like Assetic to play when working with those tools?

@l3l0
Copy link

@l3l0 l3l0 commented Nov 25, 2013

Hello I just want to describe some problems I had with integrate some frontend stuff in Symfony.

Right now most of the time when we want to install some js lib we have to download files to web or to bundle resource js dir and we need to store it in our repo. Can manage those libs can be really painfull so we (in our current project) are using separate client side app (angularjs) with configuration taken base on ng-boilerplate. I would like to see some Symfony2 project with good frontend deps convention.

I would love to have something to install and require/use frontend libs in Symfony project (via integrate by bower or npm). I mean maybe some kind of assetic:install cmd which can take into account bower.json or some else installation file... It can be event better maybe we could install and dump our frontend deps using assetic

I am not sure about how we can integrate grunt... it can probably be used separately most of the time. For sure good option will be to integrate stuff like karma spec framework with assetic watch mode... so maybe we should be able to define some commands/frontend script which can be runned using grunt things...

@docteurklein
Copy link

@docteurklein docteurklein commented Nov 25, 2013

@l3l0 It's interesting to see that grunt + bower already does all we need for frontend dev.
I think those tools replaces very well assetic.
Why calling an assetic command that would itself do nothing more than calling grunt + bower ? For the pleasure of php ? :)

Another advantage I see concerning usage of these tools instead of assetic is that they are frontend oriented.
A frontend developer who will have to work on the project will not understand all these twig fuuuuu, use_controller, bundles?, template inheritance, blocks, the debug question mark,and other tricky stuff.
He will however be more used to frontend specfic tools like bower.

To me, @willdurand resumed it very well.

@willdurand
Copy link

@willdurand willdurand commented Nov 25, 2013

I can't agree with @docteurklein more.

@ribeiropaulor
Copy link

@ribeiropaulor ribeiropaulor commented Nov 26, 2013

I agree with @docteurklein as well.

When working in the frontend of a single page app, it feels like a whole new world, different from Symfony/PHP one. It's more like consuming it like an API.

@sandermarechal
Copy link

@sandermarechal sandermarechal commented Nov 26, 2013

@l3l0 I handle front-end libs with bower. I have a bower.json file in the root of my project. I have bower install all the packages in an assets directory so I can use them with Assetic. This is the setting in my bower.json:

"directory": "app/Resources/assets/bower"

Then I can use the packages in Symfony like:

    {% block javascripts %}
        {% javascripts
            '../app/Resources/assets/bower/jquery/jquery.js'
            '../app/Resources/assets/bower/foundation/js/foundation/foundation.js'
        %}
            <script src="{{ asset_url }}"></script>
        {% endjavascripts %}
    {% endblock %}

@kriswallsmith Perhaps Assetic can make it easier to use bower packages? Referring to files like this is verbose. Defining assets in the config manually for all these packages is equally verbose (plus, you have to split the js, css, scss, etcetera in different assets).

@garak
Copy link

@garak garak commented Nov 26, 2013

My current solution for frontend libs is using composer with https://github.com/components
Indeed, I'm not very happy with it, but it's better than including frontend libs in my repo

@Spea
Copy link

@Spea Spea commented Nov 26, 2013

I created a bundle for a better bower integration with symfony2. Maybe it is of use for someone here.

@willdurand
Copy link

@willdurand willdurand commented Nov 26, 2013

@garak you can just add a bower file to your repo ;-)

@garak
Copy link

@garak garak commented Nov 26, 2013

Thanks @willdurand, I'm just exploring that way for projects in which node is not a problem. Looks good, but suggestion from @sandermarechal did not work for me, I had to add a .bowerrc file to specify "directory" option.

@l3l0
Copy link

@l3l0 l3l0 commented Nov 27, 2013

@sandermarechal oh seems to be really cool. I would like to read some blog post(s) with examples about it :)
@docteurklein @willdurand yeah I agree as well. I just think that it not always needed to create separate client side app to have really nice and clean frontend stuff - I would like to see how it can looks in project without separate client app (I thought that Assetic can help ;) ). And @sandermarechal just show me one quite interesting thing :)

@sandermarechal
Copy link

@sandermarechal sandermarechal commented Nov 27, 2013

@Spea Your bundle is pretty cool. But I wonder if it would be better to merge all the bower dependencies from the bundles into an app-specific bower.json and install that instead. I think front-end libs should be app-specific and not bundle-specific. Much like there's only one Composer vendor directory in an app. Bundles tell the app what front end libs are needed and the app makes sure they are all there.

Perhaps a similar approach would also work for Grunt? Combine all grunt tasks from all bundles into one app-level grunt file? I don't know Grunt so I may be talking nonsense.

@Spea
Copy link

@Spea Spea commented Nov 27, 2013

I don't think it would be better to merge all of them, since you may have some bower dependencies in one bundle that you don't want to use in another. But I'm planing to support a "global" bower.json, which you will place in your root dir

@webberig
Copy link

@webberig webberig commented Jan 23, 2014

I truely love working with Grunt and Bower for my own projects, but I have my doubts this is a good solution for opensource software.

I need to have some kind of distributable package that can easily be installed. I don't want my users to depend on Grunt and Bower to be able to use my bundles... That also means that making my software depend on @Spea 's bundle is a good idea...

I ideally want to use bower for asset management during development, but have the used files inside the repo for distribution...

@docteurklein
Copy link

@docteurklein docteurklein commented Jan 24, 2014

@webberig this is as strange as saying you don't want to depend on composer, but prefer having all the php deps in the repo for distribution.

@webberig
Copy link

@webberig webberig commented Jan 24, 2014

That's true. But using composer is already present when using Symfony in the first place - they are both PHP. If the software targets an audience already familiar with Symfony, composer should be familiar too... Using grunt and bower is a different story, you might end up explaining how to install node.js in your documentation.

I'm not saying it doesn't make sense to do this, but it's something I want to think (and discuss) about before blindly adding it to my software. I can't find a popular software package that doesn't include thirdparty JS plugins in its distribution package.

@docteurklein
Copy link

@docteurklein docteurklein commented Jan 24, 2014

I can't find a popular software package that doesn't include thirdparty JS plugins in its distribution package.

That's why all these popular packages should use a popular js package mechanism (aka: bower).

@garak
Copy link

@garak garak commented Jan 24, 2014

@webberig you don't need to install node.js anymore to use bower. See http://bowerphp.org/

@henrypenny
Copy link

@henrypenny henrypenny commented Feb 3, 2014

Back to the original post and KWS's follow up.

Its seems to me that Assetic works fine on a compiled requirejs project (i.e. production), but there doesn't seem to be an easy way to develop with individual js files.

Symlinking the vendor and application folders from your project into web/ could be one solution, but that would probably only work with one bundle at a time. Developers may well be working in multiple bundles, possibly with different vendor folders.

One solution could be to provide a nice means to write a basePath global var into your HTML doc (most probably the head tag):

{% assetic_base_url '@MyBundle' %}
<script>
var MyBundle_base_path = '{{ asset_url }}/js/';
</script>
{% endassetic_base_url %}

In dev this would produce:

<script>
var mybundle_base_url= '/bundles/mybundle/js/';
</script>

This could then be used in your requirejs config as the basePath.

require.config({
    baseUrl: mybundle_base_url,
    paths: {
        jquery              : 'vendor/jquery/jquery',

In production this var would be unnecessary so the tag could produce an empty string.

This would allow multiple projects to live and work inside their own bundle subdirectories.

This following code already works for me in a production context:

<script
{% javascripts '@MyBundle/Resources/public/js/main.js' %}
data-main="{{ asset_url | slice(0, -3) }}"
{%endjavascripts %}
{% javascripts '@MyBundle/Resources/public/js/require.js' %}
src="{{ asset_url }}" >{% endjavascripts %}
</script>
@henrypenny
Copy link

@henrypenny henrypenny commented Feb 3, 2014

Actually:

Its pretty easy to just hardcode the path to your symlinked project in your requirejs config:

baseUrl: '/bundles/mybundle/js/'

The config is only used in dev or while compiling. It doesn't matter what's in there in production.

A new tag is not really necessary since you'd only change that path if you changed your bundle name... which is not so common.

@henrypenny
Copy link

@henrypenny henrypenny commented Feb 3, 2014

Adding symfony console commands into grunt is pretty easy too:

    grunt.loadNpmTasks('grunt-shell');

...

        shell : {
            assetic_dump : {
                options: {
                    stdout: true
                },
                command: 'app/console assetic:dump; '
            },
            assetic_watch : {
                options: {
                    stdout: true
                },
                command: 'app/console assetic:dump --watch &'
            },
@ollietb
Copy link

@ollietb ollietb commented Jul 22, 2014

We've been using Gassetic with Symfony2 for a while now. It uses Grunt & Bower instead of Assetic, so it requires installing those packages outside of Symfony, but once it's set up it makes it much easier to manage our frontend workflow.

@henrypenny
Copy link

@henrypenny henrypenny commented Jul 22, 2014

How do you manage assets from multiple bundles?

@ollietb
Copy link

@ollietb ollietb commented Jul 24, 2014

@henrypenny Adding a javascript from a bundle is the same as adding any other path. In the example in the documentation there are javascript files from 2 different bundles.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.