Be notified of new releases
Create your free GitHub account today to subscribe to this repository for new releases and build software alongside 28 million developers.Sign up
This release fixes an issue where files nested in directories beginning with
_ weren't properly nested in the build directory. This release adds support for OS X Sierra.
- added fsevent support (file watching) for Darwin!
-gento specify where the generated sprite images
- upgraded to go1.7.1
- addresses concurrency issues within relative file analysis
This is a minor release. It includes EXPERIMENTAL support for cache busting on the --image-url and font-url. Also added support for a gulp plugin wrapper of wellington, enjoy!
Patches a couple bugs introduced in 1.0.0
- Read locks were preventing watcher from doing its job #144
- sprite paths did not correctly prefix uri to output sprites when using wt in http mode #140
- It was possible that builder could conflict on build path #139
I've reverted to leaving out the windows version. It still has a serious bug with Sass errors that makes it mostly impractical to use.
Proud to announce the 1.0.0 release with libsass 3.3.0. This marks a significant release for Wellington with multi-threaded supported by default. Sass projects will now build with the power of all cores on a system. There's been some changes to how wellington works in this release.
This release includes significant overhaul of the how files are read and built. As a result, there have been some changes to how you interact with wellington. Built files now derive their paths from the input paths. For example,
wt compile -b build sass matching files
sub/file.scss will generate the files
This process can be conflated by passing multiple paths to
wt, it's recommended to minimize the number of duplicate paths to ensure reliability of the built files. For instance,
wt compile sass/file.scss sass/1.scss sass/sub/1.scss should instead just do
wt compile sass.
With wellington being multi-threaded, libsass as well will be compiling across multiple threads at once. libsass may not be threadsafe, if you see issues please open a ticket with libsass!
The docker container's default mechanism has changed from http server to compile. If you liked the existing behavior, use
docker run drewwells/wellington wt serve to get it back. The web server is still hardcoded to port 12345.
This is the first beta marching towards the 1.0 release. You can see the issues included in this release here: https://github.com/wellington/wellington/milestones/1.0.0%20Release
libsass has been bumped to version: 3.3.0-beta1
Paths can now be passed for adding sass files. For example,
wt compile sass/file.scss sass/file1.scss
wt compile sass
With the latter, all files in the
sass directory and all subdirectories are added. This will find any files matching the pattern `[^_].+.s[a|c]ss. It's still possible to specify individual files if you desire, so backwards compatibility is maintained.
Spritewell, the library that composes images into sprites, was rewritten to be thread safe. As a result,
wt can now encode and write images to disk in separate threads. This had a significant impact on compile times, 30% in sprite heavy pages. You will also notice less sprites in your build directory. The thread-safe changes caught some race conditions that if two different sass sheets referenced the same sprite, they may create separate sprites.
Loading and sending files to libsass got a significant overhaul. We can now have libsass cranking away on all cores safely. libsass itself runs single-threaded and isn't project aware, but it is a small step towards improving build times. Single core machines won't see much benefit, they may in fact be slightly slower as a result of these changes.
This is a pre-release build, it will be available as binaries attached and may appear under:
brew install --devel wellington
You can always check out the latest master at:
brew install --HEAD wellington
Minor release to integrate upstream changes from libsass.
See the milestone for addressed bugs.
Binaries for 64bit windows, darwin and linux are attached. The container version can be checked out with:
docker run drewwells/wellington:0.9.3
This release contains a number of build improvements. We now have some remedial support for Windows (needs testing) and have improved the ways to link against libsass. Libsass is on version 3.2.5. This will be the last release before 1.0 which will coincide with the 3.3 release of libsass.
Backwards breaking changes:
CLI subcommands have been introduced. This will cause some issues if you are used to the existing method(s). As such.
wt compile main.scss
wt -watch main.scss
wt watch main.scss
- adds sprite-position support
- better compass compliance (working gulp example!) see: https://github.com/wellington/wellington/tree/4d48ea28e3/examples/gulp
- We now build windows binaries on appveyor. These are still experimental, so user beware.
It is now possible to link against a system installed libsass or to use the embedded one. To use a system install libsass, type
go build -tags dev or
go test -tags dev. This shortcuts the long build time for libsass. The embedded libsass now uses a unified build which compiles dramatically faster often under 20 seconds.
Another great release for Wellington! We have shipped a set of bug fixes and build enhancements.
- Bumped libsass to 3.2.5
- 0 dependency linux binary (not even libc) use it anywhere even Debian 6.0! #84
- Upgrade container to alpine 3.2 with go 1.4.2 package #90
- Fully go toolchain via cgo. There is no longer any need to compile an external libsass library #87
- Fixed a bug reporting proper exit codes during sass compilation errors #86
- Proper version reporting on linux binaries #79
Special thanks to @astalick for diagnosing the exit code bug.