Top Related Projects
The zero configuration build tool for the web. 📦🚀
An extremely fast bundler for the web
Rust-based platform for the Web
A bundler for javascript and friends. Packs many modules into a few bundled assets. Code Splitting allows for loading parts of the application on demand. Through "loaders", modules can be CommonJs, AMD, ES6 modules, CSS, Images, JSON, Coffeescript, LESS, ... and your custom stuff.
Next-generation ES module bundler
Quick Overview
Rome is a JavaScript toolchain that aims to unify and simplify the development experience. It combines linting, formatting, bundling, and more into a single, cohesive tool. Rome is designed to be fast, extensible, and developer-friendly.
Pros
- All-in-one solution for JavaScript development
- Fast performance due to its Rust-based implementation
- Consistent configuration and behavior across different tools
- Extensible architecture allowing for custom plugins and rules
Cons
- Relatively new project, still in active development
- May lack some advanced features found in more established tools
- Limited ecosystem compared to individual specialized tools
- Potential learning curve for developers used to separate tools
Code Examples
// Linting example
import { lint } from "@rometools/js-api";
const diagnostics = await lint("const foo = 'bar';");
console.log(diagnostics);
// Formatting example
import { format } from "@rometools/js-api";
const formatted = await format("const foo='bar';");
console.log(formatted);
// Bundling example (conceptual, as bundling is not yet implemented)
import { bundle } from "@rometools/js-api";
const result = await bundle("src/index.js", {
output: "dist/bundle.js",
});
console.log(result);
Getting Started
To get started with Rome, follow these steps:
-
Install Rome:
npm install rome
-
Create a configuration file (rome.json) in your project root:
{ "linter": { "enabled": true, "rules": { "recommended": true } }, "formatter": { "enabled": true, "indentStyle": "space", "indentSize": 2 } }
-
Run Rome on your project:
npx rome check . npx rome format .
Competitor Comparisons
The zero configuration build tool for the web. 📦🚀
Pros of Parcel
- Zero configuration out of the box, making it easier for beginners
- Faster build times due to its multi-core architecture
- Supports a wide range of file types and assets without additional plugins
Cons of Parcel
- Less customizable than Rome for advanced use cases
- May produce larger bundle sizes in some scenarios
- Limited ecosystem compared to more established bundlers
Code Comparison
Parcel:
// No configuration needed, just run:
parcel index.html
Rome:
// Rome configuration file (rome.json)
{
"linter": {
"enabled": true,
"rules": {
"recommended": true
}
}
}
Summary
Parcel focuses on simplicity and ease of use, requiring no configuration for most projects. It excels in quick setup and fast build times. Rome, on the other hand, aims to be a more comprehensive toolchain with built-in linting, formatting, and testing capabilities. While Parcel is great for rapid prototyping and smaller projects, Rome may be more suitable for larger, more complex applications that require stricter code quality control and customization.
An extremely fast bundler for the web
Pros of esbuild
- Extremely fast build times due to its Go-based implementation
- Supports a wide range of modern JavaScript and TypeScript features
- Lightweight with minimal dependencies
Cons of esbuild
- Less comprehensive tooling ecosystem compared to Rome
- Focused primarily on bundling and minification, lacking linting and formatting features
- May require additional configuration for complex projects
Code Comparison
esbuild:
require('esbuild').build({
entryPoints: ['app.js'],
bundle: true,
outfile: 'out.js',
}).catch(() => process.exit(1))
Rome:
import { rome } from "@rometools/js-api";
rome.run({
files: ["src/**/*.js"],
formatter: { enabled: true },
linter: { enabled: true },
});
Summary
esbuild excels in build performance and simplicity, making it ideal for projects prioritizing speed and minimal setup. Rome offers a more comprehensive toolset, including linting and formatting, but may have a steeper learning curve. esbuild is best suited for bundling and minification tasks, while Rome aims to be an all-in-one solution for JavaScript development workflows.
Rust-based platform for the Web
Pros of swc
- Significantly faster performance due to Rust implementation
- More mature and widely adopted in production environments
- Extensive plugin ecosystem and integration with popular tools
Cons of swc
- Steeper learning curve for configuration and customization
- Less focus on providing an all-in-one toolchain solution
- Requires separate linting and formatting tools
Code Comparison
swc configuration example:
{
"jsc": {
"parser": {
"syntax": "ecmascript",
"jsx": true
},
"transform": {
"react": {
"pragma": "React.createElement",
"pragmaFrag": "React.Fragment"
}
}
}
}
Rome configuration example:
{
"linter": {
"enabled": true,
"rules": {
"recommended": true
}
},
"formatter": {
"enabled": true,
"indentStyle": "space",
"indentSize": 2
}
}
Both projects aim to improve JavaScript/TypeScript development workflows, but they take different approaches. swc focuses on high-performance transpilation and bundling, while Rome attempts to provide a more comprehensive toolchain. swc's Rust implementation offers superior speed, making it attractive for large-scale projects. However, Rome's all-in-one approach may be more appealing for developers seeking a unified solution for linting, formatting, and building.
A bundler for javascript and friends. Packs many modules into a few bundled assets. Code Splitting allows for loading parts of the application on demand. Through "loaders", modules can be CommonJs, AMD, ES6 modules, CSS, Images, JSON, Coffeescript, LESS, ... and your custom stuff.
Pros of webpack
- Mature and widely adopted ecosystem with extensive plugin support
- Highly configurable for complex build scenarios
- Strong community support and documentation
Cons of webpack
- Steep learning curve and complex configuration
- Can be slower for large projects due to its single-threaded nature
- Requires separate linting and formatting tools
Code Comparison
webpack configuration:
module.exports = {
entry: './src/index.js',
output: {
filename: 'bundle.js',
path: path.resolve(__dirname, 'dist'),
},
module: {
rules: [
{ test: /\.js$/, use: 'babel-loader' },
],
},
};
Rome configuration:
// Rome doesn't require a configuration file for basic usage
// It provides an all-in-one solution with sensible defaults
Rome aims to simplify the development process by providing an all-in-one tool for building, linting, formatting, and bundling JavaScript projects. It offers a zero-config approach, making it easier to get started compared to webpack's more complex setup.
However, webpack's flexibility and extensive ecosystem make it better suited for complex projects with specific requirements. Rome is still in development and may lack some advanced features and third-party integrations that webpack offers.
Ultimately, the choice between webpack and Rome depends on project complexity, team expertise, and specific requirements.
Next-generation ES module bundler
Pros of Rollup
- Mature and widely adopted bundler with extensive ecosystem
- Excellent tree-shaking capabilities for smaller bundle sizes
- Supports various output formats (ES modules, CommonJS, UMD)
Cons of Rollup
- Primarily focused on JavaScript bundling, less comprehensive than Rome
- Configuration can be complex for advanced use cases
- Limited built-in features compared to Rome's all-in-one approach
Code Comparison
Rome (configuration):
{
"linter": {
"enabled": true,
"rules": {
"recommended": true
}
},
"formatter": {
"enabled": true
}
}
Rollup (configuration):
export default {
input: 'src/main.js',
output: {
file: 'bundle.js',
format: 'cjs'
},
plugins: []
};
Rome aims to be an all-in-one tool for JavaScript development, including linting, formatting, and bundling. Rollup, on the other hand, focuses primarily on bundling JavaScript modules efficiently. Rome offers a more integrated experience with a single configuration file, while Rollup provides more flexibility and control over the bundling process. Rollup's ecosystem is more mature, with a wide range of plugins available for various tasks. However, Rome's unified approach may simplify the development workflow for some projects.
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual CopilotREADME
rome
Customizable date (and time) picker. Opt-in UI, no jQuery!
Rome wasn't built in a day. Browser support includes every sane browser and IE7+.
Demo!
You can see a live demo here.
Oh, rome
synchronizes in real-time with inputs, never steals focus, and its CSS is entirely customizable!
Rome depends on moment
. It doesn't depend on jQuery or other weird frameworks, though.
Install
From npm or Bower.
npm install --save @bevacqua/rome
bower install --save @bevacqua/rome
Note that if you're using the standalone version, the API is published under the rome
global. If you're using CJS, then you'll have to require('@bevacqua/rome')
.
Setup
You can use your own distribution of moment
, using rome.standalone.js
.
<script src='moment.js'></script>
<script src='rome.standalone.js'></script>
You could just use the bundled rome.js
distribution, which comes with moment
in it.
<script src='rome.js'></script>
If you need to do anything regarding internationalization, refer to moment
for that. Ideally, make those changes before starting to create Rome calendar components.
API
The API in rome
exposes a few properties.
rome.find(elem)
If a calendar is associated to the provided elem
, then that calendar is returned, otherwise returns null
. DOM elements can only have one associated calendar.
rome(elem, options={})
This method creates a calendar instance and associates it to the provided elem
. This association can't be undone even by .destroy()
ing the rome
instance, because it can be .restore()
d later. Subsequent calls to rome(elem)
will return the associated calendar, instead of creating a new one (see rome.find(elem)
). Think of this as a "caching feature".
Creating a calendar has a ton of options. These have reasonable defaults that are easy to adjust, too. The options are listed below.
Option | Description |
---|---|
appendTo | DOM element where the calendar will be appended to. Takes 'parent' as the parent element |
autoClose | When set to true , the calendar is auto-closed when picking a day _(or a time if time: true and date: false ). A value of 'time' will only auto-close the calendar when a time is picked. |
autoHideOnBlur | Hides the calendar when focusing something other than the input field |
autoHideOnClick | Hides the calendar when clicking away |
date | The calendar shows days and allows you to navigate between months |
dateValidator | Function to validate that a given date is considered valid. Receives a native Date parameter. |
dayFormat | Format string used to display days on the calendar |
initialValue | Value used to initialize calendar. Takes string , Date , or moment |
inputFormat | Format string used for the input field as well as the results of rome |
invalidate | Ensures the date is valid when the field is blurred |
strictParse | Compares input strictly against inputFormat , and partial matches are discarded |
max | Disallow dates past max . Takes string , Date , or moment |
min | Disallow dates before min . Takes string , Date , or moment |
monthFormat | Format string used by the calendar to display months and their year |
monthsInCalendar | How many months get rendered in the calendar |
required | Is the field required or do you allow empty values? |
styles | CSS classes applied to elements on the calendar |
time | The calendar shows the current time and allows you to change it using a dropdown |
timeFormat | Format string used to display the time on the calendar |
timeInterval | Seconds between each option in the time dropdown |
timeValidator | Function to validate that a given time is considered valid. Receives a native Date parameter. |
weekdayFormat | Format used to display weekdays. Takes min (Mo), short (Mon), long (Monday), or an array with seven strings of your choosing. |
weekStart | Day considered the first of the week. Range: Sunday 0 - Saturday 6 |
Note that in the case of input fields, when initialValue
isn't provided the initial value is inferred from elem.value
instead. In the case of inline calendars, new Date()
will be used as a default if none is provided.
Inlining the Calendar
If you pass in an element other than an input tag, then this method behaves slightly differently. The difference is that appendTo
becomes the provided elem
, and the calendar won't attach itself to an input element. The options listed below will be ignored.
autoHideOnBlur
, because there is no input field that can be tracked forblur
eventsinvalidate
, because there is no input field to keep consistent with the calendar componentrequired
, because you can easily do that on an input fieldstyles.positioned
, because the calendar will be considered inlined
All of the other options still apply, and identical behavior should be expected.
Default Options
If you don't set an option, the default will be used. You can look up the defaults here, or below.
{
"appendTo": document.body,
"autoClose": true,
"autoHideOnBlur": true,
"autoHideOnClick": true,
"date": true,
"dateValidator": Function.prototype,
"dayFormat": "DD",
"initialValue": null,
"inputFormat": "YYYY-MM-DD HH:mm",
"invalidate": true,
"max": null,
"min": null,
"monthFormat": "MMMM YYYY",
"monthsInCalendar": 1,
"required": false,
"strictParse": false,
"styles": {
"back": "rd-back",
"container": "rd-container",
"date": "rd-date",
"dayBody": "rd-days-body",
"dayBodyElem": "rd-day-body",
"dayConcealed": "rd-day-concealed",
"dayDisabled": "rd-day-disabled",
"dayHead": "rd-days-head",
"dayHeadElem": "rd-day-head",
"dayRow": "rd-days-row",
"dayTable": "rd-days",
"month": "rd-month",
"next": "rd-next",
"positioned": "rd-container-attachment",
"selectedDay": "rd-day-selected",
"selectedTime": "rd-time-selected",
"time": "rd-time",
"timeList": "rd-time-list",
"timeOption": "rd-time-option"
},
"time": true,
"timeFormat": "HH:mm",
"timeInterval": 1800,
"timeValidator": Function.prototype,
"weekdayFormat": "min",
"weekStart": moment().weekday(0).day()
}
Rome API
When you create a calendar with rome(elem)
, you'll get a cal
instance back. This has a few API methods. Most of these methods return the calendar instance whenever possible, allowing for method chaining.
.show()
Shows the calendar. If associated with an input, the calendar gets absolutely position right below the input field.
.hide()
Hides the calendar.
.id
Auto-generated unique identifier assigned to this instance of Rome.
.container
The DOM element that contains the calendar.
.associated
The associated DOM element assigned to this calendar instance. This is the input field or parent element that you used to create the calendar.
.getDate()
Returns the current date, as defined by the calendar, in a native Date
object. If required: false
you'll get null
when the input field is empty.
.getDateString(format?)
Returns the current date, as defined by the calendar, using the provided options.inputFormat
format string or a format of your choosing. If required: false
you'll get null
when the input field is empty.
.getMoment()
Returns a copy of the moment
object underlying the current date in the calendar. If required: false
you'll get null
when the input field is empty.
.destroy()
Removes the calendar from the DOM and all of its associated DOM event listeners. The only responsive API method becomes the .restore
method described below, the rest of the API becomes no-op methods. After emitting the destroyed
event, all event listeners are removed from the instance.
.destroyed
Returns true
when the calendar is in a destroyed state and false
otherwise.
.restore(options?)
Restores the calendar, using the provided options (or the default options). The associated DOM element can't be changed. The API methods are restored to their original functionality.
.options(options?)
If an options object is provided, it destroys the calendar and initializes it with the provided options. Effectively the same as calling .restore(options)
immediately after calling .destroy()
.
If no options object is provided, a copy of the current options is returned.
.options.reset()
Resets the options to the factory defaults. Effectively the same as calling .options({})
while preserving the appendTo
option.
.emitValues()
Emits all of the data events listed below. Mostly used internally, should be avoided in consumer-land.
.setValue(value)
Sets the current date to the provided value
, but only if that value is valid according to the rules defined by the calendar. Takes string
, Date
, or moment
. Mostly used internally, and it doesn't emit any events.
.refresh()
Forces a refresh of the calendar. This method will redraw the month and update the dates that can be selected in accordance with dateValidator
and timeValidator
.
.back()
Steps the calendar display back by one month. Equivalent to clicking the 'back' button.
Returns undefined
.
.next()
Steps the calendar display forward by one month. Equivalent to clicking the 'next' button.
Returns undefined
.
Events
Rome calendars also provide a few events you can subscribe to. These events are published through an event emitter created using contra
. These events are listed below.
Event | Arguments | Description |
---|---|---|
ready | [options] | The calendar has been .restore d |
destroyed | [] | The calendar has been .destroy ed |
data | [value] | The date may have been updated by the calendar. Value of .getDateString() is provided |
year | [year] | The year may have been updated by the calendar. Value of moment.year() is provided |
month | [month] | The month may have been updated by the calendar. Value of moment.month() is provided |
day | [day] | The day may have been updated by the calendar. Value of moment.date() is provided |
time | [time] | The time may have been updated by the calendar. Formatted time string is provided |
show | [] | The calendar has been displayed |
hide | [] | The calendar has been hidden |
back | [month] | The calendar view has been moved back a month to the value moment.month() |
next | [month] | The calendar view has been moved forward a month to the value moment.month() |
Date and Time Validator
Please note that dateValidator
and timeValidator
both receive a native Date
object as a parameter. These methods are expected to return undefined
or true
if the date is deemed valid, and false
in case the date is invalid. If dateValidator
returns false
, the validation process will try to find a valid date near the desired date.
If dateValidator
passes for a given date, the timeValidator
will attempt to validate that date as well. If the time is invalid, the day will be probed for a valid time. This validation starts at the desired time, and grows in timeInterval
increments. When the end of the day is reached, validation resumes at the start of the day instead of leaping to the next day.
rome.val
There are a few default validator factories provided by Rome to make your life easier.
These methods take a moment
, a Date
, a string
that can be parsed into a moment
using inputFormat
, or a DOM element that Rome could use to look up another Rome instance.
If you passed in a DOM element, the validator will look up the associated Rome instance and validate using its value. The first time the validator is executed on any inline calendar, the 'data'
event for that calendar will be hooked to refresh the related calendar.
For usage examples you can refer to the demos.
rome.val.afterEq(value)
Returns whether the date is after the provided value. The comparison uses >=
, meaning it's inclusive.
rome.val.after(value)
Returns whether the date is after the provided value. The comparison uses >
, meaning it's exclusive.
rome.val.beforeEq(value)
Returns whether the date is before the provided value. The comparison uses <=
, meaning it's inclusive.
rome.val.before(value)
Returns whether the date is before the provided value. The comparison uses <
, meaning it's exclusive.
rome.val.except(left, right)
Returns whether the date is any date except the provided value. You can provide a wide variety of input values. Keep in mind Date
, string
, moment
, and the DOM element used to find another calendar are all valid input types.
Providing left
only means "any date except this one"
If you use rome.val.except('2014-08-09')
, then '2014-08-09'
is invalid.
Providing left
and right
means "any date that's not in this range"
If you use rome.val.except('2014-08-09', '2014-09-01')
, then anything between '2014-08-09'
and '2014-09-01'
is invalid.
If left
is an array, each element in the array is treated as the simple case described above
In this case, right
is completely ignored. Every item in the array is treated as follows.
If the item is single, then a rule is built on that single date
Using rome.val.except(['2014-08-09', '2014-09-01'])
means that '2014-08-09'
and '2014-09-01'
are both invalid dates.
If the item is an array, the first two items are used to determine a date range
Using rome.val.except([['2014-08-09', '2014-09-01']])
means anything between '2014-08-09'
and '2014-09-01'
is invalid.
These two types of entries can be combined in any way you like. Each entry will exclude additional dates.
For instance, [['2014-04-05', '2014-04-15'], ['2014-04-25', '2014-04-30'], '2014-05-05']
means that April 05 to 15, and April 25 to 30, along with May 05 are all invalid dates.
rome.val.only(left, right)
Identical behavior to rome.val.except
, except for the fact that the selected dates become the only valid dates, rather than the only invalid dates.
rome.moment
Exposes the moment
instance used by Rome. To change the moment
instance, refer to rome.use(moment)
.
rome.use(moment)
Sets the instance of moment
used by Rome.
Development
Start by installing any dependencies.
npm install
Then run the Gulp watch
task.
gulp watch
Lastly open the page and any changes you make just need a browser refresh.
open index.html
License
MIT
Top Related Projects
The zero configuration build tool for the web. 📦🚀
An extremely fast bundler for the web
Rust-based platform for the Web
A bundler for javascript and friends. Packs many modules into a few bundled assets. Code Splitting allows for loading parts of the application on demand. Through "loaders", modules can be CommonJs, AMD, ES6 modules, CSS, Images, JSON, Coffeescript, LESS, ... and your custom stuff.
Next-generation ES module bundler
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual Copilot