9 ms·

"There is a good chance that upgrading fails and you would need to give it a second or 3rd try." Sad that this has almost become the norm when developing in th

• vmception 6y ago
  Oh thats because you are missing the specific version manager for each part of your build toolchain And dont forget to make a script that automatically sets the right versions of npm, webpack, and python all at once! This is fine, I am okay with the events that are unfolding currently.
  • zdragnar 6y ago
    If you have multiple projects of almost any language that are stuck on different versions, you basically end up with the same problem and solution. I will definitely keep my version managers, thank you very much.
  • haar 6y ago
    I've been using ASDF (https://github.com/asdf-vm/asdf https://github.com/asdf-vm/asdf) for a while now to manage each of the language (and sometimes build tool) versions for a folder/repo in a consistent manner. I'd definitely recommend taking a look at it.
  • vangelis 6y ago
    How do you manage your version managers?
• throwanem 6y ago
  The way you avoid problems with a .0.0 release is by not upgrading to a .0.0 release. You would have to do that by hand; npm and yarn have been pinning major versions for a long time now, so that upgrade only happens when you do it by hand. So if you don't want to deal with breaking changes, all you have to do is nothing. Meantime webpack 4 is not going anywhere.
  • SilasX 6y ago
    I'm reminded of when npm released 5.7.0 (which some got upgraded to automatically because it wasn't tagged as pre-release) and had a critical bug that deleted your system files. https://news.ycombinator.com/item?id=16435305 https://news.ycombinator.com/item?id=16435305
    • throwanem 6y ago
      Why? What on Earth do you imagine that having to do with this?
      • SilasX 6y ago
        It was a new version (with significant nasty surprises), albeit .7.0 instead of .0.0.
        • throwanem 6y ago
          It was a new minor version, of a totally different package, which was version-tagged in such a way that some distro packagers picked it up when they shouldn't have, and which happened to contain a bug affecting a use case that's been deprecated for at least half a decade now. Look, I get that there's a lot of hate for modern JS, and it's hardly as if there is any lack of basis for criticism, just as there is with every other highly active, heavily adopted, and fast-evolving software ecosystem. But mistaking this kind of uninformed slagging for meaningful commentary says more about the person who does it than about the subject of their ire.
• tqkxzugoaupvwqr 6y ago
  It helps to pin dependencies so that only the exact specified version is downloaded/installed/used. I recently updated the dependencies of a frontend project. `vue-apollo` from version 3.0.3 to 3.0.4 had a breaking change. The discussion in the commit on GitHub proposed to release it as v4. But in the dev’s mind it was a fix so he released it as a patch version.
• root_axis 6y ago
  Why do you feel the need to upgrade to webpack 5? What particular feature do you need that justifies the upgrade?
  • fedlarm 6y ago
    For me the module federation is a new feature that I can take advantage of to improve integrations.
• sinker 6y ago
  So far what I've been doing is keeping my webpack config as simple as possible (< 40 lines) and just relying on default behavior. I know I'm losing out by not bothering with some of the more intricate configuration properties like caching, etc. But one of my big pet peeves is when you clone a project and the installation says all you need to do is run make install or npm i, but in reality requires 20 google searches and an hour of banging your head to get the project running and even then you end up with 50 cryptic warning messages in your terminal so you don't even know if you did it correctly. With a very simple webpack config you might lose out on optimizations but at least you can get just about anyone running a project locally and if things go awry you can generally pinpoint the problem to a specific line of configuration.
  • nicoburns 6y ago
    I've found that a slightly longer (~100 lines) webpack config allows me to use all the caching and fancy tricks I want and is still just as debuggable. I think the main thing is setting it up yourself so you know what all the plugins/settings do.
    • nwienert 6y ago
      The key is don’t abstract it. No function builders, one big object with inline conditional spreads.
    • zamber 6y ago
      Caching was a major dissapointment for me. DllPlugin is a nightmare to setup and other caching plugins I tried don't really speed things up. What eventually worked for me is HardSourceWebpackPlugin [1] - two lines added and went from 2min to 15s (with a tradeoff of a slightly longer initial build). [1] - https://github.com/mzgoddard/hard-source-webpack-plugin https://github.com/mzgoddard/hard-source-webpack-plugin
      • nicoburns 6y ago
        Not sure on the specifics, but my understanding is that the major improvements in Webpack 5 are related to caching.
• jakub_g 6y ago
  Webpack is kind of more "build your own bundler" than a bundler. The configurability and extensibility is immense and with that level of complexity, it's guaranteed things won't work smoothly for everyone (incompatible plugins, unexpected configurations etc.). Anyway, every big project always has hiccups with new major X.0.0 release. Think about your own code for a second. It's typically a well defined code that doesn't have to accommodate a combinatorial explosion of configurations. It is bug free? Keep in mind that 90% of code is written by one guy. It's not Webpack Corp. with a legion of QA testers.
  • setr 6y ago
    Run it three times however is not part of such bugginess though. It means that they're randomly encountering different executions/run-states on what should be the same config/setup, each time you run it. And they have no idea why. Or they're running things in parallel, and encountering data races and such, and randomly working as a result. But the real concern is that they don't really know what a correct installation looks like, or they'd just check-and-retry on a loop until it succeeded (the easiest hack around such problems)
    • ENGNR 6y ago
      I think it’s more if 5.0.0 doesn’t work the first time, you could simply let the community find those issues for you and by 5.0.xx it will mostly likely cover your specific setup (except for the documented api changes)
    • jayflux 6y ago
      > Run it three times however is not part of such bugginess though. It means that they're randomly encountering different executions/run-states on what should be the same config/setup, each time you run it. And they have no idea why. Maybe we’ve interpreted that message in different ways, but I took it to mean you may need to try it again at a later date once the community have fixed those issues/bugs. I don’t think they meant literally 3 runs of the same setup. They’re still working through stuff so there may be edge cases for some where 5 won’t work right now.
• jacob019 6y ago
  I know the feeling. It's not just modern stuff, I have an old ExtJS app that I dread to update. The best solution I have found is a dev / build environment in a dedicated VM that I can spin up once or twice a year to make updates. Bringing libraries up to date is a fucking nightmare and often a waste of time. For continuously updated apps I have moved away from complicated build processes. Most web apps are fine without a build process, I think there is a lot of premature optimization going on.
  • cjauvin 6y ago
    I too maintain an old and complex ExtJS 4.1 app and I never dared upgrading the framework. I carry a big zip around and it will be that until the end of its life or when I finally decide to rewrite it using React. For such an old framework it’s surprisingly bug free though.
• ronaldj 6y ago
  Configuring the modern JS toolkit (webpack, Babel, your framework of choice, Jest, etc) is such a pain. I’ve been doing front-end for 10+ years. You’re probably not a bozo.
  • folkhack 6y ago
    Same, and it's just layer on layer of extra tooling and complexity. Typescript, Babel, Webpack, JSX, TSX, etc, etc. It gets in the way of development as much as it helps.
    • cookiengineer 6y ago
      ... And suddenly, you want to insert your UI components of choice and you end up with segfault errors of node-gyp. Then you decide that not giving a damn is the sane option to maintain codebases.
      • gfodor 6y ago
        Yeah not-giving-a-damn-driven-development is also the only way to stay sane and not be over come with paralysis from being surrounded by a thousand broken windows in need of fixing.
        • ficklepickle 6y ago
          Arguably not giving a damn caused the problem in the first place
    • searchableguy 6y ago
      Deno does away with most of the tooling configuration. You get linter, bundler, docs generator, formatter, watcher, version manager, std library, inbuilt tests, and many things that you would otherwise source from third parties in node ecosystem. Support for webgpu and local storage incoming. Makes it a delight to write scripts. You can also scope them by permission. https://deno.land/ https://deno.land/ Great community: https://discord.gg/deno https://discord.gg/deno
• GordonS 6y ago
  I frequently have to rerun `npm i` when it fails for seemingly spurious reasons. We used to laugh at Windows years ago, when the solution was so often "turn it off and on again", but it's basically what you need to constantly do with tools like npm and webpack.
  • nicoburns 6y ago
    Yarn is much better in this regard. I'd thoroughly recommend it. It's drop-in compatible (except it will generate it's own lock file), so it's pretty easy to try it.
    • sebmellen 6y ago
      Yarn also gives much cleaner output. NPM is extremely verbose, but it seems that "verbosity" doesn't really confer any benefit. And yarn is also generally much faster.
    • pwdisswordfish4 6y ago
      "Subversion used to say, 'CVS done right.' With that slogan there is nowhere you can go. There is no way to do CVS right."
• hsbauauvhabzb 6y ago
  Out of curiosity is patching and updating all packages also a common consistent issue? Is there regularly breaking changes?
  • zamber 6y ago
    Depends on what packages you use and how well they do semver. Chances are you will get major version bumps for most of your dependencies after 1-2 years of development. What works well then is to do upgrades partially. Each major library separately, fix issues, go with the next one. Otherwise it's hard(er) to track what breaks your app. My current project has 100 dependencies and 150 devDependencies. Upgrading takes a week if not longer for one experienced dev. We tend to do it every 3-4 months.
• SoSoRoCoCo 6y ago
  > modern javascript ecosystem. I recently was convinced to start using a packer (webpack, parcel) and was blown away by the hoops people have to jump through to make stuff work. I've been spending an hour or so a day coming up to speed for the past few weeks, and every yarn/npm package I installed had some kind of error/warning that required a hack, or version contortion. I naively thought I could webpack with electron+vue+pug+ts and was soundly smacked down repeatedly, even after trying the boilerplate from each components' docs. I appreciate what the developers are trying to do, I really do. Only, it is too many cooks + death by a thousand cuts. As I read through pages of closed-but-not-really GitHub issues for each package, sometimes going back years and years, it feels like a constant stream of hacking that erodes the well-intentioned first versions. > but a bozo like me does not. This is actually causing me stress irl. Me too! I dread package upgrades because it can instantly turn into an all-hands-on-deck emergency, and these are just the stand-alone packages, not all the ones I mentioned above.
  • earthboundkid 6y ago
    To me what’s interesting is that ESBuild (which is a Go based JavaScript bundler) has come out of nowhere in a relatively short period of time, and it’s basically already better than any of the existing JS JS bundlers. Not just faster: it also has a radically simpler UI.
    • dntrkv 6y ago
      That makes perfect sense though. Older projects have a ton of baggage that they carry through all of the revisions. New-comers to the space can learn from the mistakes of previous approaches and also utilize the latest and greatest paradigms to solve the problem without worrying about backwards compatibility.
      • ch4s3 6y ago
        They usually have fewer features as well, and not having to support features with weird edge cases always helps.
    • 6y ago
• pknopf 6y ago
  jQuery and full-page postbacks are my go-to, unless there is an actual need to introduce something else (React, etc). I'm usually conservative in the tools I choose, but I have to be especially conservative with js.
  • darepublic 6y ago
    Full page postbacks are not necessary even if you want to go zero dep
    • pknopf 6y ago
      Most of the time, it isn't very useful to have javascript even exist, even though there isn't 3rd party dep. For example, have you even been in the settings areas of GitHub and thought "I wish there was more async here!"? In ASP.NET MVC, doing full postbacks means very simple controllers/actions/views that a junior could understand.
• manigandham 6y ago
  It's specifically the frontend ecosystem. A problem caused by the numerous languages, assets, and formats that have to come together, the lack of JS standard library, poor module system, and the disaster of browser compatibility mixed with transpilers, polyfills. Webpack has already had zero/very-little config required by default. That's what most should use, and that's if you even need to use Webpack directly. Otherwise I recommend sticking to the major site frameworks like Next/Nuxt/Gatsby and let those do all the config wiring for you.
• hankstenberg 6y ago
  Started my first React Native app some time ago and I can totally confirm that. It feels like a jungle of very fragile dependencies and mechanisms between code and output.
  • lukeramsden 6y ago
    Yes RN is certainly the worst for that for me. I can't count how many hours I've had to put in to wrangle the RN packager in to a monorepo with TypeScript and code-sharing across packages, and it's still unbelievably fragile and I can't actually share components between them. At this point I've made so many little alterations to the config from GitHub issues and StackOverflow answers that I literally have no idea how it works or how to replicate it to a new project. It's an absolute nightmare.
• d13 6y ago
  We’ve banned npm install: It’s simply a party drug and completely unnecessary.
  • deleted 6y ago
    [deleted]
• madeofpalk 6y ago
  This is why I’m such a fan of the meta-bundlers/frameworks, like create-react-app or Next.js I like the features that we pack gives me, but knowing webpack and spending the effort on configuring it just seems like a waste. I’m incredibly grateful for the CRA maintainers to handle that for me.
  • zamber 6y ago
    That works until your team doesn't decide to eject because they want to play around with webpack...
    • madeofpalk 6y ago
      Of course! Then you're just in the same hellish landscape of having to learn and maintain webpack configs, which "you" completely opted into!
• btbuildem 6y ago
  Once I had the freedom to decide, I gave up on using most of the standard Javascript ecosystem stuff in my front-end projects. No node, no npm_modules, no build chain. I'm lucky to be able to get away with that. It is incredibly efficient, not only because it no longer gets in the way of what I'm trying to build. The previous team I was on, we spent roughly 15% of our time tending to these things.
• noway421 6y ago
  Webpack itself is quite low level. `react-native init` or `create-react-app` gives you the ready to use developing environment and updating that is usually a breeze.
• thelarkinn 6y ago
  Hey Sean from webpack, this was really just about our third party plugin ecosystem needing to catch up to v5. If you are feeling IRL Stress, then please don't update yet. Sometimes you have to break things to create progress and ship major versions+bring new features. You don't have to use them, you can just use webpack's zero config out of the box.