In my gem I used the Webpack’s StatsPlugin to expose, through a JSON manifest, the path for my [webpack entry points] (http://webpack.github.io/docs/configuration.html#entry), so the Hanami can download this manifest in order to figure out the paths for the entries.
Here some key points about the implementation:
About the server, I totally agree with you about the smooth integration between webpack dev server and Hanami, in my gem I made a monkey patch on the Hanami::DevServer.start to spawn a process with the webpack dev server https://github.com/samuelsimoes/hanami-webpack/blob/master/lib/hanami_webpack/dev_server.rb#L7 to make the dev server integration transparent, I don’t know if it’s a good idea, just sounded good for me.
I’m not a specialist in Webpack or Hanami, but I’m glad to help you guys on this topic.
Not in this moment, I created the gem for a pet project that still in development. But I use the react-rails (that follow the same principles, like I said) in a production app.
I’m not sure it’s worth the pain… IMHO Hanami should focus on ruby and server side stuff. If ppl want to add some data-disable-text in a small npm package compatible with hanami (to be coupled with the webpack proposition), why not, but it’s (again, IMHO) not hanami’s job.
This allows developers to overload default environment variables (like db links) in a safe (if there’s a new env variable, you won’t miss it) and simple way (just add them to .gitignore)
Even though only .env.{{environment}}.local seems relevant in this use case, as the dotenv gem is in the Gemfile, I think that we should have load the same files as it does.
I already asked vanilla-ujs maintainer if we can submit a patch to remove that dependencies, and he agrees.
However there is an issue. That gem has application.js with a Sprockets directive that bundles together all the .js files. If we want to use vanilla-ujs we need to manually bundle them into a file (eg. ujs.js) and then we can require it from the template: <%= javascript 'ujs' %>.
We have two solutions here:
To maintain a separated hanami-ujs gem with the sole purpose of bundling vanilla-ujs files and to distribute them
@titeiko What I want to overcome here, is to have a streamlined way to perform AJAX requests.
I’m fine to not add vanilla-ujs, but still we need a fast and easy way to enable developers to work with AJAX. NPM/Webpack aren’t simple solutions. What do you suggest?
cd app/web
brew install yarn # or OS equivalent
npm install -g hanami-webpack
yarn add hanami-ajax-forms
yarn install
An hanami-webpack npm package could be the base to install a webpack environment + a command to preprocess assets (with watch option).
This way, you have a simple way for ppl that don’t want to worry about it, but anyone needing a bit more can customize its pipeline. It can also easily be added in the app generation, and be entirely skipped if the app is an api.
This is basically the same idea as laravel-mix, just a stand alone npm package with a default webpack config. @jodosha sorry for bringing up laravel stuff again