We currently use cljsbuild to compile our clojurescript source into the assets used in production, but during development, we use lein-figwheel. Both cljsbuild and figwheel are constantly watching for changes of the source and recompile when necessary.
I was wondering, whether it's possible to use just one tool for both, preferably in the same process.
We're fine with switching tools, especially Figwheel Main. Each file change should just compile:
a js with advanced optimizations to be used in production
live reload the code in the browser as figwheel & figwheel main do it
I found this in the figwheel documentation, but it requires manual work like cleaning targets and running the build on demand with special options.
I recently switched from lein-figwheel to figwheel-main (using Clojure Deps in place of lein). Figwheel-Main is much simpler, easier & better (basically it is "Figwheel 2.0").
Figwheel-Main can be used for both the auto-reloading during development and for compiling a single my-app.js output file for deployment or testing. You can use either :whitespace or :advanced compiler optimization level to get a single static *.js output file. I use :whitespace to generate an output file for standalone testing purposes (in Docker with chrome --headless) or :advanced for the final production build.
As a side benefit, Clojure Deps is better than lein for managing conflicting dependency versions.
Related
I want to separate development and production environment variables for my shadow-cljs which is running in conjunction with a lein app through the Luminus template. My production environment is a docker container running on heroku.
It should work in a way that I can import a map, say config, and so that I can access the keys using (:some-key config), or something similar to this.
There is built-in support for separating release and dev configuration.
https://shadow-cljs.github.io/docs/UsersGuide.html#_release_specific_vs_development_configuration
The "import a map and access by key" you are asking for is not supported by shadow-cljs and would be something a library would provide instead.
I also do not recommend using environment variables to configure a build.
Also note that shadow-cljs configuration is about build time. If you want to access the "environment" at runtime you do not make it part of the build at all. Say you create a :node-script build running in node. You can just access js/process.env.SOME_ENV at runtime via normal code.
I am working with an open-source application that uses libtool in its build process. I would like to statically link the local components of the application with the following intended benefits:
doesn't require libtool wrapper to launch
function calls aren't indirected by dynamic linking during debugging
avoid unintended dynamic linking to existing system-installed library
Is there a standard option to the build process that does this?
Due to dependencies on non-static system libraries I can't just use:
./configure LDFLAGS='-static'
Yes, it can be done! Use the --disable-shared option.
For example:
./configure --enable-debug --disable-shared
Now the generated executable is a directly executable binary rather than a libtool script.
This has the added benefit of roughly halving the build time.
I want to know what is exact use of npm, grunt etc. in front-end development?
Why and how to use it?
NPM is a Node Package Manager - you can think of it as a way to automate a lot of installations for you by a single command using the CL (command line). Otherwise you would have to install all the scripts manually, which is generally rather messy, since they are often not as user-friendly as say... game or standard program installations.
Grunt/Gulp/Broccoli/etc. - While I am not using it myself, from what I heard and read: It is a tool, that can help you automate numerous tasks, you would have to normally do manually. Anything ranging from compiling any CSS/HTML/JS preprocessor, concatenating different files together into one big file, watching for changes in files to automatically upload them to a server and so on. Basically it is a highly configurable tool meant to help you automate mundane and boring tasks.
Actually, NPM is a package manager what allows you to download a lot of packages of software such as Gulp and Grunt, but also Bootstrap etc with the command line. You have to install node.js for this. You don't need this as a front-end developer but it will make installing the software much easier than install it manually which take mostly more time.
https://docs.npmjs.com/getting-started/what-is-npm for npm
https://www.npmjs.com/browse/star for popular modules
Software such as Grunt and Gulp will help front-end developers mostly with compiling SASS and LESS, CSS preprocessors which saves you time and allows you to have more functions in your css. Grunt, Gulp etc runs in the command line and makes it easier to edit your files. For example, I use myself Gulp in combination with SASS. Because SASS has to compile to css I have set up a command which automatically compiles my SASS files to a CSS file if I hit the save button in my code editor, the SASS:Watch plugin.
I highly recommend using SASS, and so using Gulp or Grunt.
http://sass-lang.com/documentation/file.SASS_REFERENCE.html SASS documentation
http://gulpjs.com/ Gulp documentation
http://gulpjs.com/plugins/ plug ins for gulp
I have a project using Figwheel with ClojureScript and I'm developing a ClojureScript library. My cycle involves modifying the library, installing with lein install and then using it from the app.
The last part is the one I'm not sure about. Nothing short of lein clean in the app seems to get rid of the previous copy of the library. Having to do a lein clean and recompile every time I modify the library is very cumbersome.
Is there a better way?
you could probably add your lib source path to your cljsbuild source path in project.clj
:cljsbuild {:builds [{:id "dev"
:source-paths ["src" "/my/awesome/lib/src"]}
...}]}
so you can simply refer needed namespaces, and figwheel will recompile all the changes both in a lib and in your app. I guess this should work.
the other thing you can do is use the figwheel (reset-autobuild) command. This can be useful as it will do an implicit lein clean before re-building your cljs files.
For my current project I use Grunt as a full-deploy system. Checking/compiling all assets, cleaning cache, and deploying database. Now I am looking at Gulp.js. Everyone says, it has much more readable configuration file and it executes a bit faster. The only thing is missing for me - database deployment. With Grunt, I am using grunt-deployments package. Is there something like that for Gulp? Or should I write my own package?
Gulp is a build system. Build and Deploy are separate sets of activities. Steaming is good for building lots of smallish files like in an assembly line in manufacturing. For deployment, synchronous code (nodejs is not good at synchronous, atleast until v0.12) is good.
I use powershell(windows) or shell/chef/ansible(linux) for deployment/setup/etc, which call gulp for building assets pipeline.
Gulp is mostly targeted towards assets pipeline in other tech-stacks, and full build system for node-js techstack.
However, If you have only trivial deploy tasks, then consider using async.series() from async package and use regular node-js code to do the deployments. Accept and call the done callback when you are done in the gulp task.