webpack-encore icon indicating copy to clipboard operation
webpack-encore copied to clipboard

Add BrowserSync support

Open weaverryan opened this issue 8 years ago • 6 comments

weaverryan avatar Jun 12 '17 18:06 weaverryan

Hi,

I would like to comment here since I have an initial solution but dont know if I am missing any scenario, any help would be appreciated ;)

Currently I have this set up :

const BrowserSyncPlugin = require('browser-sync-webpack-plugin');
config.plugins.push(new BrowserSyncPlugin(
    {
        proxy: serverUrl, // coming from some settings variables
        port: serverParts.port,
        files: [ // watching on changes
            {
                match: [
                    templatesPath + '/**/*.twig', // here can go php components as well
                    outputPath + '/**/*'
                ],
                fn: function (event, file) {
                    if (event === 'change') {
                        // get the named instance
                        const bs = require('browser-sync').get('bs-webpack-plugin');
                        bs.reload();
                    }
                }
            }
        ]
    },
    {
        reload: false, // this allow webpack server to take care of instead browser sync
        name: 'bs-webpack-plugin' // notice the name when getting instance above
    }
));

This will start webpack server on localhost:8080, so I can access any assets by requesting http://localhost:8080/static/js/app.js for example, the same for css files.

Php backend application is running in another port and browser-sync is proxying every request sent to it to this backend application. Everything nice and dandy so far.

Is this what we look after for this issue ?

Points noticed:

  1. If this plugin is added. we need to check dependency is added using loader-features.js. This module name is getting name from loaders, we are not adding a loader here but a plugin. Maybe some more general module is needed for checking features?
  2. Maybe for plugins we should do the same as for loaders, from point of view of module split (utilities). This involve some refactor also. So we can have a plugin dir with utils for adding plugins.

I haven't created PR basically because of point 1. I would like to check for dependencies but it doesn't look right just add that logic in loader-features.js module as another feature for browsersync for example.

Any other ideas ?

davidmpaz avatar Jul 05 '17 10:07 davidmpaz

Awesome! About (1), you're right - we'll need to expand loader-features to support plugins... in some way :). I'm not sure exactly how that will look. But, if you do want to open a PR with any solution (even if it's hacked together), that'll help push forward discussion about the best solution. I'm actually pretty excited to be able to have this :).

weaverryan avatar Jul 05 '17 20:07 weaverryan

Happy to help ;), I am really interested to get best experience with the library :) ... I will need some time though, this week and next are packt for me, will see if find some free time on weekend to make a basic prototype to start discussion around.

cheers

davidmpaz avatar Jul 06 '17 06:07 davidmpaz

I can't really say from the related commits but is this feature implemented or only in part? If it is maybe close the issue with that statement to clarify for others stumbling upon it?

InfopactMLoos avatar Mar 06 '18 12:03 InfopactMLoos

The reason I guess this haven't been touch for so long is this comment

As I mention at the beginning, this PR will fail because of the nsp check it already reported but not got too much attention I guess on the browsersync side.

Not sure what else to do from my side :(

davidmpaz avatar Mar 06 '18 13:03 davidmpaz

Ah I seem to have missed that, thanks for the quick response. Sad to see such a lack of response from browsersync. Looking at the amount of open issues there I assume they don't have the capacity to handle all issues.

InfopactMLoos avatar Mar 06 '18 13:03 InfopactMLoos