4 ms·

I find lots of modules that won't build with Webpack and a very solid chunk of my available development time is spent trying to diagnose and fix problems caused

by hoodoof 11y ago

I find lots of modules that won't build with Webpack and a very solid chunk of my available development time is spent trying to diagnose and fix problems caused by modules that won't build under Webpack. I recommend against it.

bryanrasmussen 11y ago
can you give some examples, this article made me consider if I should rewrite my pretty developed gulp setup as webpack
- hoodoof 11y ago
  Before you do that, just try to build all the modules you use with webpack into a simple barebones app and see if your app works.
williamstein 11y ago
In contrast, I have had extremely good experience using Webpack, and my app uses dozens and dozens of modules.
Lazare 11y ago
I've never run across this, or indeed, heard of anyone have experienced this before. More details? I'm honestly curious.
- hoodoof 11y ago
  One of many examples http://andrewhfarmer.com/aws-sdk-with-webpack/ http://andrewhfarmer.com/aws-sdk-with-webpack/ Search google for webpack incompatible
  - Lazare 11y ago
    Thanks for the example.
- shados 11y ago
  It happens all the time because most UMD implementations are broken and make incorrect assumptions, so you often have to follow the "Fix broken modules" steps on https://webpack.github.io/docs/shimming-modules.html https://webpack.github.io/docs/shimming-modules.html And if your package depends on a broken module, you're essentially SoL unless you make assumptions about the path NPM will install stuff and configure webpack to fix -that- one. That's more a problem with the state of broken UMD modules than Webpack itself though, but I've considered configuring webpack to ignore all AMD syntax quite a few times...
  - hoodoof 11y ago
    Yeah the line of thinking seems to be that everything else is broken, not webpack. And the module maintainers say "well it works with everything else except Webpack so webpack is broken, they should fix it." Seriously crap situation.
    - spriggan3 11y ago
      But people should code for Webpack or JSPM or require JS or whatever. A good solution should just work no matter how the lib was coded, if it doesn't then the solution isn't worth the investment.
cnp 11y ago
If you mean old jQuery plugins or libraries that aren't CommonJS compatable, Webpack even has your back on that via its various plugins. I was able to take an extremely large node-incompatible app and "webpackify" it through the tooling in a way that would have been impossible any other way. Highly disagree.
- hoodoof 11y ago
  I'm trying to program an application, not Webpack. If there are plugins that solve some problems then why aren't they part of the default config of webpack? I'm not programming for the fun of programming build tools, I just want the damn thing to work. Zero interest in working out how to make webpack work. This is the problem with javascript build tools - they think I care enbough to want to work out how to configure them. I just want the module that I need to function.
  - shados 11y ago
    Most people don't need these things. And more and more companies have devops and infrastructure teams that can deal with that. We're still in a world where every team is a snowflake (the closest things to breaching that was Rails and other server side MVC frameworks similar to it). Once the tech slows down a bit, you'll probably see better solutions. That being said, dealing with legacy code always always suck.
    - janfoeh 11y ago
      I'd wager a bet that most people using JS today are nowhere close to having devops and infrastructure teams, but are still single people in their bedrooms copying and pasting stuff from Stack Overflow trying to make their online flower shops work. For the life of me I cannot remember who it was, but somebody once essentially said that Javascript had the quality of allowing anybody to bring to life what's in their head, no matter their skill and experience level. You could almost mash the keyboard until it worked. For me, this is a democratizing quality which is fundamental to the spirit of the web, and I would be more than happy to give up generators and class keywords for it. I've recently spent over six hours trying to build and use a JS library, fighting with package managers, build systems and transpilers, whereas earlier all I would have need to do was download a file and include a <script> tag. We're not moving in the right direction.

by hoodoof 11y ago

bryanrasmussen 11y ago

can you give some examples, this article made me consider if I should rewrite my pretty developed gulp setup as webpack

hoodoof 11y ago
Before you do that, just try to build all the modules you use with webpack into a simple barebones app and see if your app works.

williamstein 11y ago

In contrast, I have had extremely good experience using Webpack, and my app uses dozens and dozens of modules.

Lazare 11y ago

I've never run across this, or indeed, heard of anyone have experienced this before. More details? I'm honestly curious.

hoodoof 11y ago
One of many examples http://andrewhfarmer.com/aws-sdk-with-webpack/ http://andrewhfarmer.com/aws-sdk-with-webpack/ Search google for webpack incompatible
- Lazare 11y ago
  Thanks for the example.
shados 11y ago
It happens all the time because most UMD implementations are broken and make incorrect assumptions, so you often have to follow the "Fix broken modules" steps on https://webpack.github.io/docs/shimming-modules.html https://webpack.github.io/docs/shimming-modules.html And if your package depends on a broken module, you're essentially SoL unless you make assumptions about the path NPM will install stuff and configure webpack to fix -that- one. That's more a problem with the state of broken UMD modules than Webpack itself though, but I've considered configuring webpack to ignore all AMD syntax quite a few times...
- hoodoof 11y ago
  Yeah the line of thinking seems to be that everything else is broken, not webpack. And the module maintainers say "well it works with everything else except Webpack so webpack is broken, they should fix it." Seriously crap situation.
  - spriggan3 11y ago
    But people should code for Webpack or JSPM or require JS or whatever. A good solution should just work no matter how the lib was coded, if it doesn't then the solution isn't worth the investment.

cnp 11y ago

If you mean old jQuery plugins or libraries that aren't CommonJS compatable, Webpack even has your back on that via its various plugins. I was able to take an extremely large node-incompatible app and "webpackify" it through the tooling in a way that would have been impossible any other way. Highly disagree.

hoodoof 11y ago
I'm trying to program an application, not Webpack. If there are plugins that solve some problems then why aren't they part of the default config of webpack? I'm not programming for the fun of programming build tools, I just want the damn thing to work. Zero interest in working out how to make webpack work. This is the problem with javascript build tools - they think I care enbough to want to work out how to configure them. I just want the module that I need to function.
- shados 11y ago
  Most people don't need these things. And more and more companies have devops and infrastructure teams that can deal with that. We're still in a world where every team is a snowflake (the closest things to breaching that was Rails and other server side MVC frameworks similar to it). Once the tech slows down a bit, you'll probably see better solutions. That being said, dealing with legacy code always always suck.
  - janfoeh 11y ago
    I'd wager a bet that most people using JS today are nowhere close to having devops and infrastructure teams, but are still single people in their bedrooms copying and pasting stuff from Stack Overflow trying to make their online flower shops work. For the life of me I cannot remember who it was, but somebody once essentially said that Javascript had the quality of allowing anybody to bring to life what's in their head, no matter their skill and experience level. You could almost mash the keyboard until it worked. For me, this is a democratizing quality which is fundamental to the spirit of the web, and I would be more than happy to give up generators and class keywords for it. I've recently spent over six hours trying to build and use a JS library, fighting with package managers, build systems and transpilers, whereas earlier all I would have need to do was download a file and include a <script> tag. We're not moving in the right direction.