Live data from Hacker News

Show HN: Jetpack – Webpack made more convenient

github.com

71–79 of 79 posts

Re: Show HN: Jetpack – Webpack made more convenient

#71

There are a lot of "configuration-free" Webpack solutions popping up. The one thing that they all have in common is optional configuration.

Interestingly, the most common criticism of Create React App is that it doesn't allow configuration. I agree with you, though: it makes sense that they don't allow it. (Although they do have some sensible exceptions, as in: you can "configure" a CSS preprocessor like Sass by installing it.)

Re: Show HN: Jetpack – Webpack made more convenient

#72
post #70
post #33

Earlier quoted context omitted.

That's a fair point. I don't know what the best solution to this problem is, but I do think there's a problem. Requiring the users to install 20 or more dependencies (@babel/ , @postcss/ , webpack-*, etc.) and write dozens of lines of configuration every time just doesn't feel right (or maybe it is..). And we know what the developers need, they need to bundle a web project in a way that's optimised for production, js…

Despite its apparent complexity, webpack is much more suited for the common case than it is for use cases with more complex requirements. To make an analogy, webpack is the HighCharts of the js build system. If you just need a chart it’s fine for that, or if you need to configure the chart and they’ve thought to add that config option it’s fine for that too. But if you have something esoteric and instead need a set o…

That's an interesting perspective. I'd add that one option in those situations could be to utilise Webpack plugins. In one project we were bundling JavaScript with webpack in a service behind an online IDE. We used a couple hand rolled plugins to do custom resolving (find the packages in this memory-fs structured by name/version), caching (what is safe to reuse) and sandboxing (only allow safe requires and plugins).

Re: Show HN: Jetpack – Webpack made more convenient

#73
post #3

Run anywhere without installing locally, just like nodemon. I npm install everything locally, never globally, and use npm run script to easily execute (and chain) stuff. Am I in the minority?

Modules that are part of your build, tests and npm scripts should be installed locally so that any contributor can run npm install/yarn and the develop your project without any other need and they will also get the correct version of the module.

Global installs are for modules that are outside your projects dev cycle. With that in mind, a module such as nodemon can be installed both globally and locally. It depends on the use case.

Re: Show HN: Jetpack – Webpack made more convenient

#74

Woof sometimes HN can be pretty unforgiving. Remember the human guys. Good job man. Keep it up. Thanks for contributing to open source.

Agreed. Webpack's configuration is so daunting that, well, this is so obviously needed.

Not anymore! Webpack 4 is ~"zero-config"!

Re: Show HN: Jetpack – Webpack made more convenient

#75

Earlier quoted context omitted.

Agreed. Webpack's configuration is so daunting that, well, this is so obviously needed.

Not anymore! Webpack 4 is ~"zero-config"!

For a different definition of zero though. While webpack now does something useful with no configuration (which is great), you will most likely end up adding lots of configuration for any application. Whereas with jetpack there's a chance that you won't (at least in my experience).

The challenge of course is the diversity of the ecosystem. Different projects are trying to address it differently, e.g.

* CRA is opinionated and unconfigurable

* Neutrino/pwa-cli propose a higher level plugin approach (i.e. install a plugin, without needing to configure it, in webpack plugins take many lines of configuration to configure)

* Next/Gatsby use a plugin system as well but are also specialised tools which means a lot of decisions can be abstracted

* jetpack tries to be application/use case/framework agnostic and provide you with the most commonly used/useful foundation, you can optionally add extra (e.g. sass), but you don't have to recreate the foundation (i.e. es6, jsx, modern css, css modules, hot reloading, serving, producing html, etc)

It's also about the DX, jetpack lets you run a dev server with a single command, it lets you analyse the bundle with a sigle command, it builds an optimised, split chunk bundle with a single command.

Just pointing out some motivations behind the project, I'm a fan of webpack, been using it for many years.

Re: Show HN: Jetpack – Webpack made more convenient

#76
post #59
post #51

Earlier quoted context omitted.

No language has this down, but there's an environment manager (pip, rustup, rbenv..) that try to do all, and avoid the need to handle more than one "magic" session in your bashrc(etc): "asdf": https://github.com/asdf-vm/asdf Now, a few new languages do come with pretty decent "virtual env" thingy-s , but most stumble for a few years. So far (past year) I've been pretty happy with asdf. Mostly use it for ruby and node…

Another way to do this is to install Nix and direnv (and/or Emacs direnv-mode), then include a `use nix` statement in the .envrc file inside your project root. Then, when you `cd` into your project directory, your environment with all its dependencies appears. However, there are some downsides to this magical future tech: + Nix is hard to learn. + Not compatible with the standard environment managers for each languag…

Interesting. I've been considering nix, but wasn't aware of direnv. Should be a sensible combination.

Re: Show HN: Jetpack – Webpack made more convenient

#77
post #48

Earlier quoted context omitted.

It's also how militaries buy airplanes in bulk

It's also a musical duo who specializes in using "surf instruments". https://en.wikipedia.org/wiki/Jetpack_(musician)

Let's just end this here: https://en.wikipedia.org/wiki/Jetpack_(disambiguation)

Re: Show HN: Jetpack – Webpack made more convenient

#79
post #78

What was the motivation for this given existence of CRA? What are the main differences?

I'd say:

- meant to be not React only

- less opinionated in that it doesn't include jest

- smaller in scope/code, so easier to understand what it does by reading the code (?)

- allows extending configuration

- focus on SPA use case with jetpack/serve or proxy features

I should probably give CRA a proper spin though, it's popular and V2 seems pretty good.

Post reply on HN