Using Stimulus without webpack - dealing with gulp build pipeline

1

Hi there people :slight_smile:

So I’ve got a web app, that is mostly server-side rendered, and typically uses jquery to faciliate the interactions with the pages. I’ve just added stimulus into the mix, to tidy up some 'orrible unwieldly code and I’m happy with the result!

I’m using gulp currently to build my JS for production. Currently, I get all my JS files, run them through gulp-concact, then run the result through gulp-uglify, to minimize the resulting JS code.

Because I’m not using webpack, I’m adding stimulus from the unpkg source for now, and defining my stimulus controllers as per the guidelines here

Now, when I run that through my gulp pipeline, uglify complains when it encounters a controller:

Error] GulpUglifyError: unable to minify JavaScript
Caused by: SyntaxError: Unexpected token name «extends», expected punc «,»

So I’m wondering how best to handle this. Should I exclude my stimulus code from being uglified, do I need to run it through something like babel first - I’m very confused because the docs are quite focussed on this being used with webpack - and switching to webpack is a much bigger deal!

Thanks for any advice / recommendations :slight_smile:

2

Argh - so I think I realised what I need to do (plus it’s hinted at in the docs).

I need to push my controller code through babel, BEFORE I minimise it. I’ve changed to do this, and it’s working nicely for me now :slight_smile:

Maybe one day I’ll get this lot onto webpack too :grimacing:

Thanks

3

if it sounds easier for you, I could get it to work quite easily with Parcel

The nice thing about webpack is that you have the import helper and you don’t need to manually import each controller individually

4

Thanks @adrienpoly.

Agree about webpack. I spent a couple of hours looking into it and it’s not as scary as I imagined - although the weird inline css style loading made me practically lose my mind :slight_smile:

The rest of the JS in the code base is mostly written as “old style” module pattern - so I’m not quite sure how that’s going to play with webpack, whether it will just work or if I need to change it to a more modern module that webpack will understand.