does figwheel support running some other shell thing first, i.e. webpack?

@dnolen not yet I was just thinking about hooks just this moment

its always a balance since the scripting api is there now, I wonder about initialization hooks should even be offered.

and because clj -init is a thing it seems a bit redundant

but I was thinking about hooks that occur before and after each build

@dnolen and actually its a bit tricky because yarn requires a tty and so you have to do (clojure.java.shell/sh "sh" "-c" "yarn webpack")

@dnolen if you think an initialization hook is worth it to automate things like webpack let me know

I think I’m leaning towards not for now

might revisit this later

@dnolen you did see the new :npm option?

@bhauman that’s interesting but it assumes the index.js will be easy to understand semantically

I’ve run into cases where it’s better to not just reassign the import but to put the import into an object with some other name(s)

and of course other users may want to do something dynamic and then game over

@bhauman not dynamic, but an example of what I’m talking about from my class

@dnolen its just reading the window. statements

so it should work in this case right?

you don’t read the imports to compute the :provides?

and how do you line them up?

the porvides are the keys of the global exports in this case

is that to naive?

in my above snippet

how would you figure out the global exports for moment

or DatePicker

I’m not saying it can’t be done - but it needs to handle a lot of cases

and it won’t work if index.js is dynamic

yes its for the simple common case right now

right I’m just skeptical about the common case 🙂

this is a date picker

{:provides ["moment" "react" "react" "react-date-picker"], :global-exports {moment moment, react ReactDOM, react-date-picker ReactDatePicker}, :file "out.js"}

thats what my code produces

what about scoped modules?

in anycase I’m on a client project right now where this stuff comes up and it’s basic stuff they want

yeah I beleive it

its very simple sugar

that's why I didn't try to make it any more sophisticated

k, yeah I wouldn’t use something like that yet - I’m waiting to see more patterns in the wild

and then maybe can formulate a better sense of what can be automated here

absolutely, if at all

right

does the output look right though?

actually it doesn't look right at all to me

@bhauman like I said I don’t see how it could work for my example

you have to map from import to export to compute global exporst

I see what you are saying

yeah this is too naive

i love :npm in figwheel-main on 0.1.8-SNAPSHOT, long live @bhauman

awesome!

i have question, does it load 2 instance of react as one from reagent and one from webpack?

as i didn't know how, both technology blend together, i have this question on my mind for long.

@rumaysaalvina2 you would need to exclude the react from Reagent

thanks a lot again.

I'm adding a new feature called :extra-main-files that will make it trivial to add tests and devcards to a single build process. You could also add an admin build in there as well.

@bhauman Are there instructions for devcards and figwheel main? I found some for figwheel and leiningen. I don't know how to apply that to figwheel main and clj/clojure

no explicit instructions yet, but it should be the same for the most part. I will provide explicit instructions in the future after I get this feature in place

but before that I'm going to add more features to make testing trivial and then I'm going document how to test

Thank you. I got back to ClojureScript after finding out about figwheel main. It makes sense to me and all the new work I eagerly try out.