If you are upgrading from v1, there is now an upgrade helper script available that makes upgrading easier by warning you about breaking changes as your code is run. The CAUTIONLOG is also available, which is a vetted changelog showing breaking changes in order of severity.
Custom browser builds can be created on the site download page. In addition,
tools like Browserify can also be used to create custom builds, as npm packages
are now fully modular. The main repo also has tasks to create custom builds as
well. Simply clone, run
npm install then
dist directory holds builds that are ready to be loaded in the browser.
These builds include the
core module, and so have no dependencies. Bower
packages at the moment include only this directory. Use the
es5 builds if you
require support for environments that do not support ES5 natively (IE8 and below).
sugar npm package allows methods as well as entire modules to be required
individually. If you are using a build tool like Browserify, this will make it
simple to create smaller custom builds without going through the download page.
All packages also include pre-built distributions in the
In addition to the main
sugar package, there are also packages separated by
Sugar module, i.e.
When an entry point is required (the package name or an entire module), it will
return a reference to
Sugar, which is equivalent to the global object in the
browser. All methods will be defined on this object and can be called as normal.
Requiring an individual method will define it on
Sugar and additionally return
a reference to its static form that can be called immediately:
// Require all modulesvar Sugar = ;SugarNumber;// Require the Number modulevar Sugar = ;SugarNumber;// Require only the "round" methodvar round = ;;
As the npm package is designed with node in mind, polyfills must be explicitly
sugar entry point will not include them), and will immediately
apply themselves if the methods they polyfill are missing.
// Require and apply ES6 polyfills;
Similarly, date locales must be explicitly required as well:
// Require the Japanese date locale;// Require all date locales;
All Sugar npm packages are dependent on the
Although Sugar builds can now be customized at method level, modules are still
used as an intuitive way of grouping similar methods. Sugar npm packages make
use of modules, both in the main
sugar package as well as individual module
packages beginning with
sugar-. The following modules are available:
Non-default modules are excluded from the main Sugar build, but can be added by
creating a custom build. The main npm package includes the ES5
module, polyfills are disabled by default and must be explicitly required.
Other non-default modules can be found individually (i.e.
Locale definition files are in the locales directory. They can be simply included as-is after Sugar is loaded, or built together using custom builds. English is included by default and required by the Date module. Currently available locales are:
If a locale or format is missing, it can easily be added by modifying or adding the definition. See here for more on this. Please consider contributing any changes made back to the community!
Sugar does not deal with timezone abbreviations (i.e. "PST", etc). Timezone offsets will be correctly parsed if they are in ISO-8601 format (+09:00, +0900, or Z for UTC), however if an abbreviation exists it will be ignored. Sugar however plays nicely with other libraries that offer full timezone support such as timezone.js.
Date.create allows two options for dealing with UTC dates.
parse the string as UTC, but return a normal date. In contrast,
Sugar to use methods like
getUTCHours when handling the date, and is usually
used when the date needs to be formatted as UTC. Native methods like
still return local values.
Sugar now makes it easy to define your own methods. This is aimed at developers hoping to release their own plugins with Sugar. After defining methods, they can be extended or used as chainables just like other methods:
SugarNumber;SugarNumber;SugarNumber; // 95raw; // 125SugarNumber // ???Sugar;2; // 44; // 64Number; // ???
See the docs for options and other helpers.
If you would like to issue a pull request, please first consider adding well
formed unit tests. These tests can be run directly in the browser
from the test/browser/ directory or in node with
Proposals for core features or major method changes will be added to the road map. New methods may or may not be accepted, depending on their utility. Generally, they will first be delegated to plugins that may eventually be added to the main library when they reach a certain stage of popularity.