Webpack toolchain

[tchakabam]

• Adds a webpack toolchain side-by-side to the Browserify stuff
• Long-term webpack scales better on large projects to satisfy various needs
• Provides a dev-server to compile incrementally on file changes and serve bundle to test/debug/apps
• Simplifies common cases (uglifying, webworker-inline-bundles, source-mapping etc as it's all integrated with webpack, as well as other features that may be needed like conditionnality building modules, or inserting constants) - this is all very cumbersome when you need to talk to each tool on the command-line

Maybe we should consider replacing the existing toolchain with webpack completely?

[mrlika]

Thanks for PR. I am investigating proposed ability to integrate Webpack as main or additional toolchain across all the projects.

Can you advise how to use generated by Webpack P2pMediaLoaderCore.umd.js in a browser?

[tchakabam]

a UMD (see libraryTarget) is the universal module definition target type. you can either load it in a script tag and then it will be exported in the global scope (window or global in Node.js) under the library name. or you can just use it as a proper ES6 module and have it required in any other toolchain by other code, and bundle it into a new module (like you would when you import something as an npm package). So in short, UMD build can be used for script tag and npm package.

You can also use the this and var settings on libraryTarget parameter, and those are respectively exporting the library into the this scope of the import context, which in a script tag will be window, or global in Node.js, and var hoists the export in a top-scope var so that it is available for all child scopes, but it's not set in the global/window environment. You usually only need those build types for very specific needs.

Anyway it is very easy to produce several types of builds at once, or depending on the environment (prod/debug).

I would also recommend that you use global exports as little as possible and build everything "in-tree" to one bundle, once the final demo application is built.

Another possibility with Webpack is to always import dependencies even if they might be available in the global scope, and then configure them as "externals". That way your code is formaly requiring all dependencies it uses, and you can decide wether this will be resolved at build or at runtime (from the environment somehow as global or var import). See https://webpack.js.org/configuration/externals/

[tchakabam]

@mrlika This isn't too important, but working with webpack eases a lot the development process i think.

There are other proposals concerning the P2P technology and the player integration, testing and scaling that I would like to make! ;)

[mrlika]

Yes. I was expecting it to behave this way when I loaded it using a <script> tag. It uses window object as root but factory() returns undefined:

root["P2pMediaLoaderCore"] = factory();

[tchakabam]

I see. There might some details about how you did your public API that we have to look into to get this right. But I am confident that whatever you want to do is included in webpack. But moreover I believe it is more scaleable.

For example you could have one webpack config for the core, and the different player integrations, and the demo, building all various assets/bundles in parallel, but serving them from one local dev host. Or building integration tests for all that etc ... You can centralize your build config and then choose what to do depending on your environment.

In fact as your architecture tends to be something that will have like "plugins" for each player/streaming engine, you will probably want to go with a build system that is more extendable :)

[tchakabam]

@mrlika Just wondering, in fact I'm not sure I understood what the factory bit is in your example. Where does that come from? I may miss a part here.

What I actually do is, I try to build an own "plugin" for a player here, and in the same strike I also try to build an integrated toolchain for the project here. As I get this to work, I'll update the PR here with my proposal. Currently not everything might work as I haven't validated it with the end-to-end build, but I am on it at the moment.

My aim is that one can build the demo, plugins and the core in one dev-server process.

[tchakabam]

@mrlika Understood the issue you re seeing, and that factory is referring to the actual UMD build output. Yes, there is something we missed here to get the TS exports actually out there. Should be easy to fix, looking into it :)

[tchakabam]

The problem was "too much config" :) This works now so far in terms of exporting things.

[mrlika]

My apologies for the slow reply; had no time to review the PR because of vacation.

Using you PR as a base I managed to configure cross-project incremental build via webpack.

Also configured exposing module into window.p2pml object for webpack bundles in the same way as it is now done with browserify that makes both builds compatible.

I am still testing and finalizing the changes. And in case of no issues will include webpack toolchain into the projects.

[mrlika]

Done. Now webpack incremental build is supported.
You should "npm link" the projects and run "npm run webpack:watch" for each project that you are going to modify.