figwheel-main 2020-01-07

ingesol10:01:58

@mikerod I recently spent a lot of time trying to figure this out. I landed on generating the different files for dev, prod, test, etc. Not optimal, but for now better than duplicating and spreading out.

ingesol10:01:46

Some cases could possibly be covered by using CLI options. The docs are a bit vague and spread around, but schema is here https://github.com/bhauman/figwheel-main/blob/master/src/figwheel/main/schema/cli.clj

ingesol10:01:32

But I think this means that you can EITHER specify a file containing EDN, OR an inline EDN string. Specifying both, where the inline string merges into file contents would be nice

mikerod14:01:35

@ingesol thanks. Yeah that makes sense to me. It’s a bit weird to work with it seems indeed.

Brian Abbott19:01:42

How do we has figwheelists view ShadowCLJS? Are they complimentary to each other, seperate but equal or TOTALLY MUTUALLY EXCLUSIVE?

athomasoriginal00:01:34

My perspective is that they are two tools that provide a similar set of functionality (admittedly, shadow provides more help in the interop department with NPM). Personally, I like Shadow and admire the work thheller is doing, but I have no reason to switch my projects to Shadow at this point in time. Hope this helps answer the question 🙂

plexus09:01:34

I recently switched a project from fw-main to shadow, and had to change how some 3rd packages are used, so now my code is no longer compatible with fw-main. With fw you mostly rely on cljsjs, with shadow you use stuff directly off npm. How a certain package is invoked in both cases may or may not be source compatible.

plexus09:01:02

Just something to be aware of. I still somewhat prefer figwheel-main for the familiarity and easy integration, but objectively shadow does everything that figwheel does equally good or better, and if you need a lot of third party npm packages it is the only thing that really works reliably.

athomasoriginal18:01:03

@U07FP7QJ0 That’s a good point!

2020-01-07

Channels