:npm-deps
to be true
as well as false
Releasing 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 :compiler
A 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-always
figwheel.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 is a website building & hosting documentation for Clojure/Script libraries
× close