Closed zoepage closed 4 years ago
Moved grunt eslint
-> eslint
as first step in https://github.com/webcompat/webcompat.com/pull/1365
@magsout Can we start to list which grunt tasks need to be moved to webpack? What the task take care of and how we want to replace them?
PATHS: jsPath: "webcompat/static/js", cssPath: "webcompat/static/css", imgPath: "webcompat/static/img"
@zoepage
yes
don't know how.yes
yes
We need:
webpack.ProvidePlugin
(global object like jQuery, backbone)resolve
: alias all global script (jQuery, backbone etc...)@zoepage I think it's a good start https://gist.github.com/magsout/f9fd40c35102f9184b7566a707b00daa
However it is for version 1
We need to follow https://webpack.js.org/guides/migrating/
related to #897
I'm sure this is something fun, that @lewiscowper could handle really well? :)
👍
Hej, I would love to work on this.
I have quite a bit of experience by moving our build toolchain from Grunt over Gulp to webpack 4.x.
By having a quick look at the sources I saw that you are using the revealing module pattern to organize your JavaScript.
I would recommend switching to use Babel in addition to webpack and use ES modules instead. But I’m not sure if I can handle that within this PR. That would require digging deeper in your sources and I have no time right now.
Because of the timing: I would love to jump in and work on that right now. Sadly I’m pretty busy at least until Mid May. But we’ll have a Open Source Friday within our company on May 18th. So I could start working on the PR not later than that.
18th of May sounds really great for me. Until then we can figure out a "detailed" plan of how to move things and to see, if we don't run in any issues?
@Regaddi @magsout and I are also happy to help and do work. :)
+1 on babel as this is something we were discussing for some time now.
My thoughts on how to replace the grunt tasks in a webpack environment.
Not part of webpack. Should be run independently, to keep build time shorter.
Not necessary, when we use package-lock
file.
Can be done with postcss (e.g. node-css-mqpacker)
Use require
to build those files.
Can be done with webpack and css-loader (which uses cssnano)
Can be done with postcss-loader or independently with postcss-cli.
This is either the webpack-dev-server or hot module replacement or a combination of both.
Sweet, thanks @Regaddi :)
cssmin
is also something we can replace by purifycss
and this is an option already included there https://github.com/webcompat/webcompat.com/blob/master/package.json#L61
With webpack it would be most convenient to have a dev bundle and a production/staging bundle. Currently we're referencing the JS source files in DEV mode (see https://github.com/webcompat/webcompat.com/blob/issues/1714/webcompat/templates/layout.html#L50). We should probably replace this with a JS Dev bundle using sourcemaps. This would also allow the introduction of babel and modern JavaScript language features 😄
@miketaylr what do you think?
Not part of webpack. Should be run independently, to keep build time shorter.
We are on the same boat. I use a neat little package of mine to get a notification when linting fails while watching, though.
We should probably replace this with a JS Dev bundle using sourcemaps.
Jup. I will set things up similar to this one I set up recently:
Heya, thanks @mischah for wanting to help out. :)
+1 on babel as this is something we were discussing for some time now.
I'm -1 on babel right now, unless there are very strong user-facing arguments for it.
I want to be very conservative about introducing Babel and anything that might lead to shipping more JS than we need to, just so we can use cool JS syntax. We have to keep in mind that Firefox users end up at webcompat.com when they try to report new issues, and they're all over the world on all kinds of devices and networks.
If someone can show that moving to ES6 + Babel makes things smaller and faster, then let's consider that! But right now my opinion is that developer ergonomics don't beat the simplicity of just using ES5.
That said, webpack is a step in the right direction, and codesplitting will be a big win for performance (do we need to move to modules to get that to work? maybe we convert first to commonjs/AMD? Maybe?) once we get there.
And yeah, +1 to sourcemaps/dev bundle @Regaddi.
If someone can show that moving to ES6 + Babel makes things smaller and faster, then let's consider that!
(Note: i realize doing all that work and running tests is a big up front investment)
I'd love to see babel land mainly for promises, but I do not mind it landing later on. :)
(Note: i realize doing all that work and running tests is a big up front investment)
💯 I second that!
oh cool thanks a lot @mischah 😀
I tried to add webpack two years ago, but I did not succeed. But the cool things,
Webpack has evolved and the documentation is much clearer.
I had problems with this
and others window
, which I think may have been set with loader as import-loader, but I had errors that I did not understand. So I'm very interested to see how you integrate webpack.
Hej is it normal, that npm run lint:js
reports the following in the master branch:
✖ 4897 problems (4897 errors, 0 warnings)
😳
Ok, that was a weird and edgy issue 😕
Created #2458 to fix that.
let's try again
Hey, that's pretty neat. Do you have a plan to tackle this? I was kinda engaged into this but I got stuck in an infinite loop of reading their docs(webpack & grunt docs). Anyway! maybe I can help!
We've migrated to webpack in https://github.com/webcompat/webcompat.com/issues/2900, so I think this can be closed
Move the grunt setup to webpack4 like already mentioned in #909
PATHS: jsPath: "webcompat/static/js", cssPath: "webcompat/static/css", imgPath: "webcompat/static/img"