3 ms·

> Webpack is not hard, the config is a simple javascript app that has to return an object following a specific schema There's so many variations in what stacks

> Webpack is not hard, the config is a simple javascript app that has to return an object following a specific schema There's so many variations in what stacks people are using and what build steps are required for different projects that setup issues and bugs to workaround are virtually inevitable. I want to move up to the next major version of Webpack for one project for example but after spending a total of several days getting my builds working correctly already, I'm almost certain it'll eat up at least a few days to get everything working again (e.g. production and development builds, source maps, live reloads, hot reloading, template compilation, TypeScript compilation, SASS compilation, project paths, optimizations). Saying it's just simple JavaScript is completely overlooking all the plugins and configuration you have to stitch together and when things go wrong it can be challenging to know what to Google for.

manigandham 9y ago
I understand, but that's more of an issue of there being so many external plugins. The entirety of webpack itself is just a small core runner with plugins and they're slowly moving more functionality into the main package. Fundamentally I think the issue just comes down to terrible documentation and the spread of outdated blogs and examples as a result. The team seems to know that and they're working on it but it should be the highest priority for them. Honestly though, starting from scratch, you can build a complex config (with all those things you mentioned) in about 30 minutes. If you really need help then post it here or on stackoverflow and you'll get an answer pretty quick.
- seanwilson 9y ago
  > Honestly though, starting from scratch, you can build a complex config (with all those things you mentioned) in about 30 minutes. If you're sticking to a pre-built template or simple defaults maybe but once you start to customise things it's easy to get stuck in your own unique problems. Resolving path issues can easily eat up 30 minutes alone so I'd say you're severely underestimating. > If you really need help then post it here or on stackoverflow and you'll get an answer pretty quick. Once you've got your own unique combination of plugins going, it gets difficult to know where the problem is and you're less likely to get help if you've got something bigger than a minimal example. I know how to ask for help but there's just something about build system which makes it more challenging and more frustrating to get help compared e.g. typical programming problems.
  - manigandham 9y ago
    I'm not sure why paths are such a big issue. The config object only needs the path to your applications entry file, and the path to where to put the output. All the paths within your app js (the import() statements) dont have anything to do with webpack and wouldn't run anyway if they were wrong. What other paths are you running into problems with? Also debugging this is just like any other app, start with 1 line at a time and see what changes. You can technically run it all inside of a debugger but that's a lot of setup so the old-school 1 change at a time + console.log() statements work well. Remember its just a single-file js app that produces an object.
    - myspy 9y ago
      The issue is that for the result there are too many variables and unknowns that complicate the most important thing. Writing the app and not taming the build process. Take Ember for example. It lacks the freedom to configure as you please but gets you going creating very fast.
    - conradfr 9y ago
      It is with the paths in your styling (images, fonts) which by default are checked and rewritten during compilation (which fails if he can't find the files).
jwdunne 9y ago
I feel your pain. Tried moving away from bower + simple gulp concat to pure NPM and webpack on an old angular 1.x app. Ouch. Webpack as of now reserved to just vendor. Porting the whole app over will take a significant amount of work. I don't have that at the moment, not with 2 or 3 deadlines on my plate!

manigandham 9y ago

I understand, but that's more of an issue of there being so many external plugins. The entirety of webpack itself is just a small core runner with plugins and they're slowly moving more functionality into the main package. Fundamentally I think the issue just comes down to terrible documentation and the spread of outdated blogs and examples as a result. The team seems to know that and they're working on it but it should be the highest priority for them. Honestly though, starting from scratch, you can build a complex config (with all those things you mentioned) in about 30 minutes. If you really need help then post it here or on stackoverflow and you'll get an answer pretty quick.

seanwilson 9y ago
> Honestly though, starting from scratch, you can build a complex config (with all those things you mentioned) in about 30 minutes. If you're sticking to a pre-built template or simple defaults maybe but once you start to customise things it's easy to get stuck in your own unique problems. Resolving path issues can easily eat up 30 minutes alone so I'd say you're severely underestimating. > If you really need help then post it here or on stackoverflow and you'll get an answer pretty quick. Once you've got your own unique combination of plugins going, it gets difficult to know where the problem is and you're less likely to get help if you've got something bigger than a minimal example. I know how to ask for help but there's just something about build system which makes it more challenging and more frustrating to get help compared e.g. typical programming problems.
- manigandham 9y ago
  I'm not sure why paths are such a big issue. The config object only needs the path to your applications entry file, and the path to where to put the output. All the paths within your app js (the import() statements) dont have anything to do with webpack and wouldn't run anyway if they were wrong. What other paths are you running into problems with? Also debugging this is just like any other app, start with 1 line at a time and see what changes. You can technically run it all inside of a debugger but that's a lot of setup so the old-school 1 change at a time + console.log() statements work well. Remember its just a single-file js app that produces an object.
  - myspy 9y ago
    The issue is that for the result there are too many variables and unknowns that complicate the most important thing. Writing the app and not taming the build process. Take Ember for example. It lacks the freedom to configure as you please but gets you going creating very fast.
  - conradfr 9y ago
    It is with the paths in your styling (images, fonts) which by default are checked and rewritten during compilation (which fails if he can't find the files).

jwdunne 9y ago

I feel your pain. Tried moving away from bower + simple gulp concat to pure NPM and webpack on an old angular 1.x app. Ouch. Webpack as of now reserved to just vendor. Porting the whole app over will take a significant amount of work. I don't have that at the moment, not with 2 or 3 deadlines on my plate!