Request: Figwheel main support #403
Comments
|
My understanding is that Figwheel main is meant for standalone usage, and Figwheel plugin is used from Leiningen. @bhauman am I correct on that? :) |
|
They are completely different code bases. Figwheel main is often used from Leinigen. |
|
I believe Figwheel Main is "The" Figwheel going forward, in terms of ongoing maintenance, new features etc. |
|
I'm a bit unclear on the relationship between the two at the moment, @bhauman would you recommend switching over to Figwheel main, will both projects be maintained? |
|
I absolutely recommend switching.
…On Tue, Dec 11, 2018 at 3:18 PM Dmitri Sotnikov ***@***.***> wrote:
I'm a bit unclear on the relationship between the two at the moment,
@bhauman <https://github.com/bhauman> would you recommend switching over
to Figwheel main, will both projects be maintained?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#403 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAAKQCs5veSoenT8q6n0a3LfN2kW16Yhks5u4BL8gaJpZM4ZAegn>
.
|
|
I see, thanks for the heads up |
|
Looking at the docs page, it doesn't look like there's any integration with Leiningen though. I really liked the option for keeping Figwheel config in project.clj, is this just not going to be possible going forward? |
|
@bhauman is it possible to pass the config to Figwheel main as an explicit parameter? If that was the case, I would write a Lein plugin that could start it that way. While understand the benefit of Figwheel being able to run standalone and have its own config, I think there's value in having integration with Leiningen as it's the most widely used built tool. |
|
Did you look at the documentation that I linked it shows how to use
figwheel.main as an alias in Leinigen.
…On Tue, Dec 11, 2018 at 3:50 PM Dmitri Sotnikov ***@***.***> wrote:
@bhauman <https://github.com/bhauman> is it possible to pass the config
to Figwheel main as an explicit parameter? If that was the case, I would
write a Lein plugin that could start it that way. While understand the
benefit of Figwheel being able to run standalone and have its own config, I
think there's value in having integration with Leiningen as it's the most
widely used built tool.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#403 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAAKQK1wtftAqcupbfF5ABJlkCaisa6vks5u4BqwgaJpZM4ZAegn>
.
|
|
This is a much better solution. You should give it a try and see how it
works before creating a plugin.
…On Tue, Dec 11, 2018 at 4:04 PM Bruce Hauman ***@***.***> wrote:
Did you look at the documentation that I linked it shows how to use
figwheel.main as an alias in Leinigen.
On Tue, Dec 11, 2018 at 3:50 PM Dmitri Sotnikov ***@***.***>
wrote:
> @bhauman <https://github.com/bhauman> is it possible to pass the config
> to Figwheel main as an explicit parameter? If that was the case, I would
> write a Lein plugin that could start it that way. While understand the
> benefit of Figwheel being able to run standalone and have its own config, I
> think there's value in having integration with Leiningen as it's the most
> widely used built tool.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#403 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AAAKQK1wtftAqcupbfF5ABJlkCaisa6vks5u4BqwgaJpZM4ZAegn>
> .
>
|
|
@bhauman the docs suggest using an alias like I don't really see any downside to supporting this functionality. The plugin could literally just run |
|
Reasons I advocate this:
* Figwheel starts much much faster
* having one way to config figwheel, means the configuration can be easily
read outside of the leinigen process
which will enable folks to use `clj` to launch a quick CLJS
rebel-readline repl.
* it potentially less expressive if you make a plugin, and more command
line features are added, whereas using the
alias has a direct mapping to the command line args, and doesn't hide
them.
It's very straightforward to make a plugin to start figwheel-main, I
intentionally chose not too.
…On Tue, Dec 11, 2018 at 4:04 PM Bruce Hauman ***@***.***> wrote:
This is a much better solution. You should give it a try and see how it
works before creating a plugin.
On Tue, Dec 11, 2018 at 4:04 PM Bruce Hauman ***@***.***> wrote:
> Did you look at the documentation that I linked it shows how to use
> figwheel.main as an alias in Leinigen.
>
> On Tue, Dec 11, 2018 at 3:50 PM Dmitri Sotnikov ***@***.***>
> wrote:
>
>> @bhauman <https://github.com/bhauman> is it possible to pass the config
>> to Figwheel main as an explicit parameter? If that was the case, I would
>> write a Lein plugin that could start it that way. While understand the
>> benefit of Figwheel being able to run standalone and have its own config, I
>> think there's value in having integration with Leiningen as it's the most
>> widely used built tool.
>>
>> —
>> You are receiving this because you were mentioned.
>> Reply to this email directly, view it on GitHub
>> <#403 (comment)>,
>> or mute the thread
>> <https://github.com/notifications/unsubscribe-auth/AAAKQK1wtftAqcupbfF5ABJlkCaisa6vks5u4BqwgaJpZM4ZAegn>
>> .
>>
>
|
|
I understand all that, but I'm asking why both ways can't be supported if it's just a matter of exposing the entry point in Figwheel. This seems to be very prescriptive, and while it's a great choice for a lot of situations, I think it would be nice to allow users to decide how their project configuration works. Allowing for a lein plugin doesn't detract from the current approach, and people can switch between them trivially if they want to. |
|
@bhauman another problem with this approach is that it's no longer possible to share cljs compiler config. This is error prone because you have to remember to make changes in two places now. I really hope you'll reconsider to allow supplying Figwheel configuration explicitly even if it's not your personal preference. Please consider that everybody has different use cases, and different priorities for their build process. I'm not asking for a plugin, just the ability to make one so that I can use the tool in a way that fits best with my current setup. |
|
The luminus template has a default and is prescriptive correct? And you are
offering an alternate prescription? Thus my advocacy.
Also we are having this conversation before you have learned much about or
even used figwheel-main. My prescription is based on my time creating it
and working with it.
…On Tue, Dec 11, 2018 at 4:23 PM Dmitri Sotnikov ***@***.***> wrote:
I understand all that, but I'm asking why both ways can't be supported if
it's just a matter of exposing the entry point in Figwheel. This seems to
be very prescriptive, and while it's a great choice for a lot of
situations, I think it would be nice to allow users to decide how their
project configuration works. Allowing for a lein plugin doesn't detract
from the current approach, and people can switch between them trivially if
they want to.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#403 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAAKQMm7c9SbJ9If6ybQlHxKZ0qe0eGTks5u4CJggaJpZM4ZAegn>
.
|
|
Luminus is a template, people can easily make other templates that fit their workflow. Right now it's not possible to me to use Figwheel main in a way that doesn't fit with your preference. |
|
You can merge configurations on the command line `-b base-dev:dev`.
…On Tue, Dec 11, 2018 at 5:20 PM Dmitri Sotnikov ***@***.***> wrote:
@bhauman <https://github.com/bhauman> another problem with this approach
is that it's no longer possible to share cljs compiler config. This is
error prone because you have to remember to make changes in two places now.
I really hope you'll reconsider to allow supplying Figwheel configuration
explicitly even if it's not your personal preference. Please consider that
everybody has different use cases, and different priorities for their build
process. I'm not asking for a plugin, just the ability to make one so that
I can use the tool in a way that fits best with my current setup.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#403 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAAKQICX9x9bLkXeF083GvvvKVb_npYtks5u4C-tgaJpZM4ZAegn>
.
|
|
but my configuration lives in project.clj because I need it to create the uberjar. |
|
For context, the applications my team works on have both client and server components. The applications are packaged as jars for releases containing all the build artifacts. In our scenario, it makes a lot of sense to have a central configuration file instead of duplicating it across multiple ones. |
|
I hear you, and again I'd ask you to learn about it and use it before
making decisions.
…On Tue, Dec 11, 2018 at 5:25 PM Dmitri Sotnikov ***@***.***> wrote:
For context, the applications my team works on have both client and server
components. The applications are packaged as jars for releases containing
all the build artifacts. In our scenario, it makes a lot of sense to have a
central configuration file instead of duplicating it across multiple ones.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#403 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAAKQB1l4uWhm3utKfr6LWppZtq-vesaks5u4DDOgaJpZM4ZAegn>
.
|
|
I'm trying to learn it, but I'm running into problems around the workflow, and as far as I can tell there aren't adequate solutions to those. Currently, the usage from Leiningen appears to be strictly worse than it was with figwheel-lein. In my case start up speed is not of interest, and being able to keep a single configuration in one place provides a lot of value. I also don't see how it's faster to launch from lein as a separate process as an alias. I still have to wait for lein to start, and then wait for Figwheel main to start after. Is that not the case? |
|
I ran into similar issues as @yogthos trying to use figwheel.main. While I understand your reasons for the changes, @bhauman, there are use cases that worked with "old" figwheel that are no longer supported by figwheel.main. If you're going to recommend that devs make the switch then existing workflows should be supported going forward. |
|
Often what happens to me in conversations like this is that I initially remember/feel that something is a not a good idea, without remembering the complete context and reasoning behind it. This is often because time has passed and I'm way out of the context that generated the initial thinking. When folks press me for why and I provide an incomplete answer hoping that it will suffice, knowing that I don't quite remember all the reasons. This is a bit lazy on my part as I'm not quite motivated to go back and revisit all my reasoning for this, and then take the time to write out all the trade offs the led me to that conclusion. I ask folks to take my word for it and hope that it will suffice and then I experience frustration when it doesn't. This is not an ideal response. However communicating these things doesn't come easy to me, it takes more time than you may imagine. In this particular case, the main reason for this trade-off is around the need to be able to read the build configuration from the While it's difficult to get data out of the project.clj it's trivial to get data into the project.clj by simply slurping/merging compile configuration files. The state of things right now, is if you only add "figwheel-main" to your dev deps in the Figwheel-main also works well with Cursive because of this simplicity. And, as stated before, this also allows one to use Figwheel with deps tools as well. For these reasons I advocate having the configuration outside of the project.clj. The relative benefit of having the production configuration be a convenient profile switch that prevents some duplication, compared to eliminating the need to use and maintain a monstrosity like Especially considering that the potential duplication of config can be eliminated by simply reading the build config into the project.clj. In response to the question about speed and Leinigen. Plugins are what make Leinigen slow. Whereas Leinigen is AOT compiled, plugins have to be resolved and loaded dynamically. |
|
Thanks for the detailed response. I completely understand your reasoning for not wanting to maintain a library just to handle merging data between profiles. Reading config into project.clj would help with the duplication, but it would still be useful to pass that configuration to Figwheel as a parameter. In general, I do like that there is no inherent coupling between Figwheel and Leiningen right now. I obviously wouldn't ask you to incur the burden of having to maintain complex tooling you don't use. However, I hope it's not too unreasonable to facilitate passing in the configuration explicitly as opposed to requiring that it's read from a file. I can see this being useful in a number of situations such as running Figwheel from the REPL with a synthesized config for example. And the AOT vs plugins makes sense, although realistically I tend to already have plugins running from |
|
Yes figwheel.main has a scripting API that allows directly passing
configuration.
https://figwheel.org/docs/scripting_api.html
…On Wed, Dec 12, 2018 at 10:01 AM Dmitri Sotnikov ***@***.***> wrote:
Thanks for the detailed response. I completely understand your reasoning
for not wanting to maintain a library just to handle merging data between
profiles. Reading config into project.clj would help with the duplication,
but it would still be useful to pass that configuration to Figwheel as a
parameter. In general, I do like that there is no inherent coupling between
Figwheel and Leiningen right now.
I obviously wouldn't ask you to incur the burden of having to maintain
complex tooling you don't use. However, I hope it's not too unreasonable to
facilitate passing in the configuration explicitly as opposed to requiring
that it's read from a file. I can see this being useful in a number of
situations such as running Figwheel from the REPL with a synthesized config
for example.
And the AOT vs plugins makes sense, although realistically I tend to
already have plugins running from ~/.lein/profiles.clj and Figwheel isn't
going to break the bank. At least with my workflow, I tend to just leave
Figwheel running and might restart it a handful times a day.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#403 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAAKQKivlAgIZRf15H5PRdz2Ugc4GESIks5u4RpOgaJpZM4ZAegn>
.
|
|
Oh, that's exactly what I was looking for. 👍 |
|
Hi! I was wondering if there was any updates in this area by any chance? Thanks! |
|
I ran into a few snags with the classpath, and haven't had a chance to look into this since. |
|
May be related to #467 since I think figwheel-main might treat deps.edn as first class. |
Since this looks like it will be the future of figwheel, it would be great to have a
+figwheel-mainin addition to the current+figwheel, for those like me, struggling to understand the best way to configure things.The text was updated successfully, but these errors were encountered: