luminus-framework
Request: Figwheel main support
Since this looks like it will be the future of figwheel, it would be great to have a +figwheel-main in addition to the current +figwheel, for those like me, struggling to understand the best way to configure things.
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.
https://figwheel.org/docs/installation.html
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 [email protected] 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 https://github.com/luminus-framework/luminus-template/issues/403#issuecomment-446347021, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAKQCs5veSoenT8q6n0a3LfN2kW16Yhks5u4BL8gaJpZM4ZAegn .
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 [email protected] 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 https://github.com/luminus-framework/luminus-template/issues/403#issuecomment-446357023, 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 [email protected] 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 [email protected] 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 https://github.com/luminus-framework/luminus-template/issues/403#issuecomment-446357023, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAKQK1wtftAqcupbfF5ABJlkCaisa6vks5u4BqwgaJpZM4ZAegn .
@bhauman the docs suggest using an alias like {"fig" ["trampoline" "run" "-m" "figwheel.main"]} to run Figwheel. That means the configuration has to be kept externally and managed outside project.clj. I don't see any option to be able to keep the config together. I strongly prefer having all the configuration in one place because then I can control the options via profiles.
I don't really see any downside to supporting this functionality. The plugin could literally just run figwheel.main and pass it the config it reads from project.clj. Am I missing anything as to why this would be problematic or not desirable?
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
cljto 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 [email protected] 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 [email protected] 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 [email protected] 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 https://github.com/luminus-framework/luminus-template/issues/403#issuecomment-446357023, 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 [email protected] 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 https://github.com/luminus-framework/luminus-template/issues/403#issuecomment-446367191, 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 [email protected] 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 https://github.com/luminus-framework/luminus-template/issues/403#issuecomment-446384568, 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 [email protected] 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 https://github.com/luminus-framework/luminus-template/issues/403#issuecomment-446386072, 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 project.clj. This is something that you need to be able to do if you want to start Figwheel from a REPL which includes cider-jack-in-cljs and using Cursive. In order for this important workflow to work well in figwheel-sidecar I had to create https://github.com/bhauman/simple-lein-profile-merge which made the workflow more possible but as we know doesn't work in every case. Quite frankly having to write that in the first place was an incredible pain. It's quite painful to extract profile applied data outside of the project.clj, and because its difficult to do and doesn't work sometimes it leads to very confusing situations when it doesn't work. So this compared to the simplicity of reading an EDN file seems like an interesting trade-off which decreases the complexity of whats needed to carry your configuration to figwheel, and increases the understanding of how the configuration is read and used.
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 project.clj, and you setup the configuration as recommended in a dev.cljs.edn file you can have a CIDER cljs-repl with no other configuration, by simply doing cider-jack-in-cljs and selecting figwheel-main as an option. It has never been so easy to get a reliable Clojurescript REPL in Emacs.
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 simple-lein-profile-merge.
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 ~/.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.
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 [email protected] 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 https://github.com/luminus-framework/luminus-template/issues/403#issuecomment-446617894, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAKQKivlAgIZRf15H5PRdz2Ugc4GESIks5u4RpOgaJpZM4ZAegn .
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 https://github.com/luminus-framework/luminus-template/issues/467 since I think figwheel-main might treat deps.edn as first class.
