A tiny, no-fuss development setup intended for small projects and experiements. It's purpose is to help ease the beginnings of a project by giving you a little develop setup to get things up and running as fast as possible without needing to fuss around with remembering all of the common npm packages you might need to work with ES6.
Once you're done, you can even build with the tool as well.
Two ways Method one
npm install -g kantan
Note that if you use method 2 and a custom webpack config - you may have to install additional packages for your project.
Kantan is primarily intended for use as a development server, but can also be used to build packages(note - building bundles is still under re-write).
Each form has some available options. You reference all options on the command line or you can
specify a json or js file to write your config in and pass in a path to that file with the flag
--buildadd this flag if you want to build files instead of running the dev server
--portspecifies the port to run the server on
--entryspecifies the path to the main entry file for your app/site
--publicspecifies the directory that contains your html
--customWebpackSpecifies the path to your own webpack.config.js file. Will use a default file if one is not specified.
--buildCSSBy default - css isn't being built to help reduce memory and processing constraints. Add this flag to include the css loader in the compiled webpack config. You can then include css like you normally would with style-loader/css-loader by going
include css from '<path to your css file>
Previously, there was the option to build a bundle in a common js compatible format. Now that ES6 is starting to be directly integrated into browsers, it's assumed that ES6 is what you're going to be building with and common js support is removed.
There are some sensible defaults set up now but if need be you can pass in a custom json file specifying build options.
--buildConfig flag above.
This dev setup is primarily meant to JS based projects, but CSS parsing is included as well. This is utilizing PostCSS as a pre-processing step as it has a large variety of plugins to change your css however you'd like. By default, it'll compile scss syntax using PreCss. From previous testing, there isn't a difference that I can find yet, but keep in mind that this isn't using the normal Sass rubygem.
Note that this no longer uses chokidar and is all tied into Webpack.