Deprecating meta.js

[psychobunny]

Use grunt instead. Perks include (for developers) not having to wait for minification for vendor scripts and being able to further optimize reload speeds.

Also see #3542

[psychobunny]

Optional build parameters for plugins (ex. Coffeescript and ES6) will be supported

Related: https://github.com/NodeBB/NodeBB/issues/3247

[psychobunny]

https://github.com/NodeBB/NodeBB/issues/3542

[alkhe]

Webpack is great for our use case. It's really fast and supports pretty much everything we need. (Coffee, ES6, chunking, minification, etc.)

[psychobunny]

I probably will stick to this as I am more comfortable with grunt and browserify. Could you give me reasons why you think webpack is a better solution? Want to keep our options open.

Note that we are going to write our own grunt plugin to detect installed components and compile them. This currently includes templates, theme and plugin assets, sounds, and a couple more.

[psychobunny]

Also browserify lets us use commonjs syntax, which makes it much more appealing for libs that are used on both server and client.

[alkhe]

Webpack lets you pick and choose from CommonJS/2, AMD, and var. It's being used for all the latest isomorphic libs right now.

Integration with different loaders and plugins is really easy. Babel, pretty much the de facto ES6+ to ES5 code transpiler, has super easy integration. It also has module chunking for multi-page apps and efficient live reloading during development.

Webpack essentially subsumes browserify and gulp, which subsumed Grunt.

[julianlam]

What are your thoughts on systemJS, @edge?

[alkhe]

I tried it once, and I was pretty disappointed. It's a cool idea, but it has quite a lot of overhead in multiple areas.

Webpack is basically the way forward.

[julianlam]

Thing is, we don't want to overhaul this system with a library that might get completely passed over in 6 months' time :wink:

That said, we're still on Require.js, so if anything, that's long in the tooth...

[alkhe]

Webpack's already become pretty much ubiquitous in the React community, as well as in the post-2015 project culture. It probably won't be going away any time soon.

[pitaj]

Use Webpack. It supports everything you need, plus it will have dead code removal in the future. I've been using it with Babel and writing everything in ES6 - really awesome.

[julianlam]

Hi @pitaj, nice to see you around again :smile:

Seems like the consensus is for webpack...

[alkhe]

fyi, webpack already has dead code removal with uglify.

[pitaj]

Ivory only removed dead code that isn't referenced or exported within the file itself. It doesn't handle tree scraping to remove all possible dead code including unused exports, etc.

[julianlam]

It looks like migrating to webpack may be possible... it'll require some finesse since it would require overhauling the code to replace both grunt, uglifyjs, and require.js... not to mention all of the support code we have to make NodeBB work well with those aforementioned items.

[julianlam]

... holy moly you can assign multiple people to an issue now! :clap:

[pitaj]

Webpack will import and bundle AMD, CommonJS, and standard module syntax. You don't need to convert anything, but you can if you want.

[julianlam]

@pitaj running into an issue where module is required that requires a server side module and then starts a chain of requires that end up bundling half of node_modules/ with it.

Any thoughts?

[pitaj]

Split the server side stuff and client side stuff into separate files, and require the client side stuff in the server side file. On Jun 3, 2016 11:42, "Julian Lam" notifications@github.com wrote:

@pitaj https://github.com/pitaj running into an issue where module is required that requires a server side module and then starts a chain of requires that end up bundling half of node_modules/ with it.

Any thoughts?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/NodeBB/NodeBB/issues/3543#issuecomment-223477468, or mute the thread https://github.com/notifications/unsubscribe/AAxDdW8qJEEBb8dv3UaCB0xj3ZWrZW9Iks5qH5SvgaJpZM4F2POU .

[julianlam]

Doesn't this defeat the purpose of shared node modules? 😛

[julianlam]

The other one is this: https://github.com/NodeBB/NodeBB/blob/master/public/src/ajaxify.js#L223-L231

It causes webpack to require everything in node_modules/ too :frowning:

[julianlam]

okay, so I did this:

{
  "external": ['translator']
}

... and that worked ok... not feeling 100% due to these little workarounds. Earlier this evening webpack couldn't find fs because it's a Node.js built-in, and the workaround is to do { node: { fs: "empty" } }, because why not...

[pitaj]

Why are you requiring fs on the client side? OR: Why are you using Webpack for server stuff?

[julianlam]

I believe it was the shared files (used both on server and in client-side). In any case, this experiment didn't pan out...

[akhoury]

+1 for webpack

[lo1tuma]

For plugins and themes I would actually prefer if the plugin/theme author could choose the build tools by himself. Which means that nodebb core should expect that the plugin is already transpiled/minified/whatever and simply do nothing.

Apart from that I would also like to see an option to have the build separate from the application runtime in order to be able to ship a version to production which doesn’t include any build tools. Usually build tools require quite a lot of memory and a lot of them even leak memory. This could be avoided by not using them during application runtime.

[pitaj]

The issue with that, @lo1tuma, is that NodeBB must compile templates, scripts, and less before running. It is possible to pull this out into a different command entirely, though. A build for production step, then a run step.

[julianlam]

That is quite a novel idea, and to be honest, one of the reasons why NodeBB does everything on start is simply due to it being an artifact of our prior knowledge as PHP developers 😆

By this point I think there's no real reason to separate it out into a build step and a run step. That may be a good starting point for later revisions to use things like webpack, gulp, etc.

[lo1tuma]

@pitaj Why must this done by nodebb? Why can’t it accept ahead of time compiled versions of teplates, scripts and css?

@julianlam If nodebb wouldn’t automagically build plugin/themes file then it wouldn’t matter what build tool nodebb uses.

[Radiergummi]

@lo1tuma since plugin template partials need to be merged with theme template partials, templates can only be compiled at startup time.
I have been playing around with webpack a lot lately and find it too cumbersome and overloaded (see my implementation here). Gulp produces way more beautiful code that is easier to understand and work with. I know Webpack has support for chunk loading and stuff, I'd favor gulp in combination with babel anyway though.

[barisusakli]

@lo1tuma since plugin template partials need to be merged with theme template partials, templates can only be compiled at startup time.

A separate build process can determine the current theme and load all templates in the correct order.

I think this is a good idea this way we can remove the code we have that sends js/css payload between child workers.

Another added bonus would be restarts would be a lot faster if there are only core server side js changes and there is no need to run ./nodebb build

[lo1tuma]

@Radiergummi Unfortunately I don’t know the technical details about nodebbs template engine. From my experience with other template engines (e.g. handlebars) you can pre-compile them to a javascript representation which then can be merged with other templates.

I also don’t quite understand why you are trying to compare gulp with webpack. Gulp is just a task runner where webpack is a module bundler. Actually you can even use both. You can implement a gulp task which just executes webpack. You can also use babel as a loader for webpack. There are also other alternatives, e.g. rollupjs wich is what I’m most interested in using.

[Radiergummi]

@lo1tuma The reason being, partial integration is no part of templates.js, the engine NodeBB uses, but a task performed by NodeBB itself. You could surely do this beforehand, though users would have to perform a startup task after every plugin installation then.

I know you can use both, I am actually doing so in my current project. But you can achieve most of the things webpack does with gulp and gulp plugins aswell. Thats just my personal opinion though, and I'm no core dev, so don't care too much about it :wink:

[Radiergummi]

@lo1tuma half a year passed, Webpack 2 was released, I'm a fan. Opinions change quickly 😄 Coming to think of the build process, writing a loader for .tpl files would be completely feasible. Webpack also has the flexibility to create a plugin/theme integrated workflow, especially concerning split bundles for plugin functionality.

[lo1tuma]

Opinions change quickly

Exactly. That’s why I think we should allow the plugin author to make the decision which build tool he wants to use.

[pitaj]

I think we could support either. Add new clientEntries and serverEntries fields in plugin.json to pass into webpack and a flag for which ones to import automatically. People can use that if they want or can use the old scripts and acpScripts if they have something simpler.

[barisusakli]

We use webpack since 2.x, gonna close this since we still need meta/js.js to handle plugins etc.