:npm-deps to be true as well as falseReleasing this to support nREPL changes
Daniel Compton did some great work solving the caching issues.
There is also a very confusing problem with lein trampoline on Windows
see issue #682. So I turned off the auto-trampoline feature for
Windows which allowed the for the elegent use of Rebel readline by
just calling lein figwheel.
Windows users can still elect to use trampoline with figwheel and get the benefits of rebel-readline but the will have to call lein trampoline figwheel and this should be done with the knowledge that they may experience a classpath corruption issue.
A big thanks goes out to ClojuristsTogether.org and everyone who contributed for helping to make this work possible!
This release includes the biggest change that Figwheel has had in
quite a while. After 2 months of work I'm proud to release a version
of Figwheel that has Clojure readline support. Even if you always use
your editor REPL like me, you may want to try the REPL that lein figwheel launches. You may find that its a handy tool to have around.
You can learn more about rebel-readline at https://github.com/bhauman/rebel-readline.
Don't forget this gets rid of the need for rlwrap.
You can disable the Rebel readline by adding :readline false to your
:figwheel config.
This release requires that you use
[org.clojure/clojurescript "1.9.946"] at least.
This release also, adds automatic support for projects that use Code Splitting. You should now be able to use code splitting and have Figwheel "just work".
Other changes:
:preloads for figwheel client injectionFigwheel inherited a topo sort algorithm from the CLJS compiler. It turned out that this graph sorting algorithm missed a very important optimization, which is fixed in this release. If you have project that has a lot of namespaces and have experienced slower load times when you change a file that is deeper in your dependency chain, you should notice a big improvement when using this release.
Added JavaScript environment hooks for tools like re-natal to
customize the websocket implementation and the script loading behavior.
improved topo-sort algorithm
CLJS compile option: the :entries key is no longer required in the
:modules configs
new :repl-eval-timeout allows you to increase or lower the
Figwheel REPL eval timeout as a top level config setting
added goog.global.FIGWHEEL_WEBSOCKET_CLASS to allow one to
override or supply a websocket implementation for the figwheel
client
added goog.global.FIGWHEEL_IMPORT_SCRIPT to allow one to override
or supply a function to the figwheel client, that is responsible for
loading a namespace into the JavaScript runtime.
added two new namespaces that can be supplied the ClojureScript
compiler's :preloads option.
The two namespaces are only different in that one set's up figwheel while the other both sets up and starts figwheel. These are currently meant to clean up how the figwheel client is injected into the build. The next release of Figwheel will do away with generating a small ClojureScript file to inject the Figwheel client into build.
figwheel.connect which will take a configuration from
:external-tooling > :figwheel/config and supply a
figwheel.connect/start function which contains the supplied
config options. This function is exported so that it can be easily
called from JavaScript.figwheel.preload which simply calls the above figwheel.connect/start
function:process-shim to validation codeThere have been constant problems when reloading an application into
Chrome where even a hard reload insists on pulling items from the
cache. Adding no-cache to the response headers headers and returning
appropriate not-modified responses is a trade-off that will
hopefully address this issue without adversely affecting initial load
performance. Keep in mind that this will only apply to Figwheel's built-in
dev server. If this becomes a problem for some projects we can explore
adding a flag for this behavior.
aget:fn-invoke-direct to validation schema:source-map-asset-path to validation schema:load-test to validation schema:npm-deps to validation schemaI knew when I started validating compiler options that there was a trade-off. On the one hand I can create really specific errors (i.e. spelling errors) if I do a hard check for key membership, but with the down side that as figwheel trails the compiler development new options would couse the config to fail validiation.
I figured this would be a good trade off considering that:
A. Compiler options will be added at a slower and slower rate as time goes on.
B. In general newer compiler options are geared towards more advanced users who understand the trade-off of opting-out of config validation.
One can opt-out/tune this behavior with the :validate-config option:
:validate-config (false | :warn-unknown-keys | :ignore-unknown-keys)
and skip unknown key validation all together.
In the top level figwheel config one can now place some lifecycle hooks, to easily add more services to the process that figwheel is running in.
For example:
:figwheel { :init user/start-server
:destroy user/stop-server }
Also:
Figwheel used
Compojure
in its server to handle routing. This was convenient but was also overkill
for the simple routing that Figwheel needs. This also made the routing
a bit more complex for the downstream :ring-handler.
Just recently a strange issue
https://github.com/bhauman/lein-figwheel/issues/428 popped up. Strange
things where happening when wrap-reload was being used in an
embedded :ring-handler.
There is so little routing functionality in Figwheel that I just replaced the Compojure routing with simple Ring middleware. This is much more predictable and has the added advantage of removing another dependency from Figwheel.
If the behavior of your :ring-handler changes (routes not being
resolved, bad/missing HTTP headers etc.) please let me know.
For reference here is the commit: https://github.com/bhauman/lein-figwheel/commit/f027b10188ed9d1baa6ec04bbdd14e6a493f68b0
The lein plugin uses config data from the project.clj (or figwheel.edn) before it has been validated, I added some extra safe guards to protect against initial use of this data.
figwheel-sidecar/get-project-builds which was removed in 0.5.4
its now here to stay.before (start-figwheel!) only optionally took a configuration. Now it
takes optional build-ids as well.
So you can do this:
(start-figwheel! "dev" "admin")
And it will pull in the config from the environment and start autobuilding the supplied build ids.
Or you can supply a config and build ids ...
(start-fighweel!
{:figwheel-options {:server-port 4000}
:all-builds [{:id ...}]}
"dev" "admin")
I have also beefed up the error checking and feedback around this call.
This is the most solid release of Figwheel so far ... enjoy!!
This means you will see the compile errors and warnings displayed along with the offending code and a pointer to the position of the failure. This is a big improvement. I've found that even for simple errors, that I've become accustomed to, the new errors tend to beam the information into my head much more quickly.
The code pointers are rough at times and no code context information will be displayed if Figwheel doesn't get any line and column information from the compiler.
The new error display can be improved further, and I plan to do so. I just wanted to get the bits hooked up and a decent display out the door first.
There have been several correctness problems that have dogged Figwheel for a while.
The most important change here is that I have made all code that runs in the plugin only depend on libs that are either natively available in Clojure or are included with Leiningen. This should rid us of the many ways that Figwheel was incompatible with other plugins and environments. I really had to learn the hard way that this is the only way to develop Leiningen plugins, and in hindsight, it makes a lot of sense.
A downside of this is that Figwheel "appears" to start slower. But all
my tests have shown that it is starting slightly faster. And .... as
a bonus lein trampoline works very well with Figwheel now.
If you are not already familiar with lein trampoline, the following
command will cache the startup args the first time it is run, and will
only launch one JVM on the next execution.
LEIN_FAST_TRAMPOLINE=y lein trampoline figwheel
In my setup I have the following script in on my path. Using it shaves seconds off of my startup time
file::/User/bhauman/bin/figt
#!/bin/bash
LEIN_FAST_TRAMPOLINE=y rlwrap lein trampoline figwheel "$@"
:source-paths change or if certain ClojureScript compiler
options change. This means that if you add a dependency in your
project.clj the next time you start figwheel it will detect that
change and clean out the build assets before compiling. If you have
a simple classpath that points to a directory of jars this won't
help you, but I think this will help a great majority of users.This is a user experience improvement experiment. There has been a problem when the initial compile fails and you open the browser and nothing happens and your REPL doesn't work.
Inspired by Elm, I am now emitting a small application that announces the problem when you load it in the browser. This application is a figwheel client so that it will respond to and display compilation messages and will provide a REPL execution environment.
It won't load compiled files but as soon as a compilation succeeds it will auto-refresh and thus pick up your correctly compiled application.
It's still early but I'm thinking that this could be a good feature.
Folks who have been using (figwheel-start!) from the REPL have been
confused by Figwheel's inability to merge in the default Leiningen
profiles.
Figwheel will now merge Leiningen profiles without needing to load
leiningen-core.
This behavior is new and not comprehensive but will probably work fine for the majority of cases where someone has a little profile merging in their project.clj
The Figwheel lein plugin has added commands and better command-line feedback for bad args.
The new commands are
lein figwheel :once build-ids ...
Which will do what lein cljsbuild once does, with figwheel error
messages. This command won't inject the figwheel client code.
lein figwheel :check-config
Which will run validation on your configuration.
lein figwheel :help
Which prints out the same help information as lein help figwheel
You should take a moment and read this help information.
Expect a :watch command in the next release....
:build-options in favor of :compilerA younger, more idealistic version of myself, wanted to have a different
key for compiler options. So I used :build-options internally. As
usual that younger version of myself had no idea what he was doing.
If you are using :build-options you will get a validation error
saying that it is deprecated and that you should use :compiler.
:build-options is still being used internally but I am saving it as
technical debt.
(start-figwheel!) now validates the configuration
and throws useful exceptions if a configuration problem is found(println "hi")
and see the output in the REPL. This works for nREPL as well as a
direct cljs.repl.(js/setInterval #(println "hi") 1000)
in the REPL works sending output to the REPL:open-urls option in the per-build client :figwheel configuration.
This is a vector of URLs that Figwheel will open the first time a
build completes. These are opened with clojure.java.browse/browse-url.
You could put http://cljs.info/cheatsheet/ info in there :):figwheel > :ansi-color-output false:open-file-command script a third
argument that is the column position of the problem. Yes this means
that heads up display errors can pop you to the line and column
if you click on them.:open-file-command so that one can debug it more easily:ring-handler exceptions and general printing output to the
figwheel-server.logwindow.location was being called in a node environment:figwheel > :load-all-builds false:repl false configuration option(reload-config) REPL command, reports config errors nowI'm planning on investing some time in fixing up the error messages. This is just a first take.
figwheel-start! so that they don't return the SystemMap
as this was behaving badly in various REPL configurations 28e03affigwheel-sidecar.repl/get-project-cljs-builds and deprecated(build-once) work for builds that aren't opt none(clean-builds) work for builds that aren't opt none:cljs-build-fn figwheel option.clj or .cljc macro reloadingcljs.build.api/build:recompile-dependents default value bringing it inline with cljs compiler defaults:nrepl-middleware server configuration has been added (see readme)
Thanks to Okke Thijhuis @otijhuis, give him a shout out!:ring-handler a var so it picks up changes - thanks to @nikitonsky(figwheel.client/toggle-autoload) or figwheel.client.toggle_autoload() in the dev console:foreign-libs, :libs
and Google Closure libs in your :source-paths that follow Clojure
namespacing conventions - this is hot!(require ... :reload) and (require ... :reload-all) work correctly now:reload-dependents client config parameter. It forces the "reloading"
of files that are dependent on changed files. This is very fast operation and can
potentially obviate the need for ^:figwheel-alwaysfigwheel.connect works:server-ip server config option to all folks to not
default to binding "0.0.0.0" which exposes the connection to the network:devcards option to figwheel client config, more on this later:websocket-host :js-client-host option to allow the client to use the location.host of
the loaded page. Thanks to @peterschwarz[cider-nrepl 0.9.0] a little more easilyreload-config special-fn in the repl:figwheel is
set in the build(reset-autobuild) REPL command now reloads the build config
from your project.clj:optimizations, :output-to, :output-dir:fighweel true to builds that you want
figwheel to run on. The client code will be injected to the build.
You can inspect the generated client code in
target/figwheel_temp/<build id>/fighweel/connect.cljs:false starts two compile processes:id caused NPE^:figwheel-always was causing a double file reload when editing the marked ns:modules configurations was
preventing figwheel from starting:nrepl-port along
with a port number to the :figwheel config in your project.clj will
start an nREPL server into the running figwheel process.
https://github.com/bhauman/lein-figwheel/wiki/Using-the-Figwheel-REPL-within-NRepl:autobuild to false will disable
the automatic loading of code on file changes. Now that the cljs REPL
development experience is maturing it's nice to have the option to do
REPL only development. Its a client side option so that you can change
back and forth between the styles of development fairly easily.:recompile-dependents is false:url-rewriter client config option shouldn't be
needed in most cases now. If you are currently using :url-rewriter it will
be broken as the form of the url argument is changing.:on-jsload but just having app restarting/rerendering code
(like React.render) at the bottom of your root application file.^:figwheel-always can now be added as meta data to cljs namespaces that
you want to be reloaded whenever there is a file change in your source
tree. With this flag you won't really need :on-jsload, even for complex
setups. Namespaces marked figwheel-always do not have to be required.
So you can put this on your test runner namespace and viola!, you will have
your tests running in the client env on every reload. Pretty cool.cljs.user ns after refreshing the browser.:debug is a new client config option, when it is truthy figwheel
will print out copious amounts of debug information.:load-unchanged-files is a client option that if set to false will cause
the client to not reload files that haven't changed. With this option set to
false files will only load if their content has changed. This option defaults
to true.(in-ns 'your.cljs.namespace) and poke around$ rlwrap lein figwheel
you can install rlwrap on OSX with brew: brew install rlwrap:repl false in the :figwheel config:server-logfile in
:figwheel config:notify-command, figwheel now honors
:notify-command only on successful compiles, this should be especially helpful to
those who are using :notify-command to run testsorg.clojure/clojurescript "0.0-2665" or greater(ns ^:figwheel-load example.core(ns ^:figwheel-no-load example.setup:load-warninged-code true in the figwheel clientdefonce macro. It is built into cljs:heads-up-display false in the client configemacsclient or your editor's equivalent working correctly.
In the :figwheel configuration in your project.clj you need to include
an :open-file-command option. This should be the name of a script on your
path that takes a file and a line number. The reccomendation here is to write
your own script and put it in ~/bin.:open-file-command is emacsclient aware so you can just provide "emacsclient"
as an option and it will just work.46 commits and many more changes
defonce and not ClojureScriptsCan you improve this documentation? These fine people already did:
Bruce Hauman, bhauman, Ikuru K, Mika Vilpas, aJchemist & Colin YatesEdit on GitHub
cljdoc builds & hosts documentation for Clojure/Script libraries
| Ctrl+k | Jump to recent docs |
| ← | Move to previous article |
| → | Move to next article |
| Ctrl+/ | Jump to the search field |