Add BrowserSync support

[weaverryan]

No description provided.

[davidmpaz]

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 ?

[weaverryan]

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 :).

[davidmpaz]

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

[InfopactMLoos]

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?

[davidmpaz]

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 :(

[InfopactMLoos]

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.