rome/tools

Unified developer tools for JavaScript, TypeScript, and the web

Important

Welcome to Biome, the community successor of Rome!

Warning

Rome won't be maintained anymore by the same people that maintained it so far. Biome will provide new features and fixes.

Rome is a formatter, linter, bundler, and more for JavaScript, TypeScript, JSON, HTML, Markdown, and CSS.

Rome is designed to replace Babel, ESLint, webpack, Prettier, Jest, and others.

Rome unifies functionality that has previously been separate tools. Building upon a shared base allows us to provide a cohesive experience for processing code, displaying errors, parallelizing work, caching, and configuration.

Rome has strong conventions and aims to have minimal configuration. Read more about our project philosophy.

Rome is written in Rust.

Rome has first-class IDE support, with a sophisticated parser that represents the source text in full fidelity and top-notch error recovery.

Rome is MIT licensed and moderated under the Contributor Covenant Code of Conduct.

Documentation

Check out our homepage to learn more about Rome, or directly head to the Getting Started guide if you want to start using Rome.

Technical documentation

Browse Rome's internal Rust API Documentation if you're interested to learn more about how Rome works.

tools's Issues

This scope does not allow `var`iables.

Description:

I get the following error when trying to bundle a hapijs server.

This scope does not allow variables. This is probably because variables were injected into a scope that did not contain var in the original source.program

Error occurred while requesting compile for project-quick-server/@hapi/hapi/lib/config.js

Steps To Reproduce

☂️ Public API

The rome package will likely be the only package published for users. This will contain the CLI and a very thin API that heavily limits the public API exposed. There's no intention to publish any other packages as this would heavily restrict the changes we can make.

• Custom project finding logic exists that matches the CLI behaviour. This is necessary due to the lack of a server #6 .
• All exposed methods will be async. This does prevent Rome from being integrated in some tools as sync callsites are only possible, but we don't want to limit the sort of work we can do.

Logo

The current logo is OK but it would be nice to have something a lot simpler. It was created with an SVG I purchased which was modified with illustrator and the lines smoothed out and color with shading added.

Project config file - minimize API

One of the project goals is to minimize the API, but right in the getting started guide, we see the project configuration "can take three possible forms": rome.json, rome.rjson or "rome" entry in package.json.
Already too many options. Is there a case where a project won't have a package.json!?

IMHO we should stick to "rome" entry in package.json.

Semver Parsing error for versions which are NPM aliases

Description:

I'm trying to bundle a node hapijs app and running into an issue where versions which are npm aliases are failing.

Steps To Reproduce

Try bundling a basic hapijs server. It's getting stuck in the package.js file of one the dependencies on "@hapi/joi-legacy-test": "npm:@hapi/[email protected]"

I'd be glad to create a fix if you point me in the right direction.

☂️ Linting

The current area of focus for Rome is linting. This is the path of least resistance for finishing a part of Rome that can be used most easily.

With diagnostics #3 the lints that Rome can produce will be more detailed than any other existing JS linter. The most difficult part of this will be editor integration and writing a set of lint rules.

One large question is how we handle configuration. Are we going to take an opinionated stance and have some lints non-configurable? Will we have plugins?

Create symlink to rome/dist folder

Hi,

Context

1. I have run ./scripts/build-release dist.
2. Then create test project with next package.json

{
  "name": "rome-hello-world",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "compile": "rome compile src/index.js",
    "lint": "rome lint src/index.js"
  },
  "author": "i.mirdzhamolov",
  "license": "ISC",
  "devDependencies": {
    "rome": "file:../rome/dist"
  }
}

Problem

When try to run npm run compile or npm run lint I get error

~/projects/rome-hello-world $ npm run lint       

> [email protected] lint /Users/i.mirdzhamolov/projects/rome-hello-world
> rome lint src/index.js

/Users/i.mirdzhamolov/projects/rome-hello-world/node_modules/.bin/rome: line 1: syntax error near unexpected token `('
/Users/i.mirdzhamolov/projects/rome-hello-world/node_modules/.bin/rome: line 1: `(function(global) {'

What I do wrong? 🤔

Add ignore property to format project config

Non-capturing groups

All the regexes I see in the code use capturing groups, but don't make use of the captured group. Not sure what percentage of performance is related to the regexes, but just wondering if you have tested using non-capturing groups to see if it makes a significant difference? Maybe you have already figured this out and are going with the easier to read option. Babel does the same thing.

☂️ Add tests

I'm not very good at writing tests. This issue is to track tasks involved with writing tests for a stable release.

• Add js-generator tests #17
• Update js-parser tests #11

RJSON

Rome contains a custom JSON parser at packages/@romejs/codec-json. The primary motivation for building this was JSON.parse does not emit detailed information for syntax errors. So I decided to build a vanilla JSON parser with detailed errors that emits Rome diagnostics (#3).

Once I had this built, it was quite easy to add JSON extensions. So I did. They are only enabled when a filename is passed in that ends in .rjson, so the parser can parse with and without.

These extensions do not add additional data types and are purely syntactic. When using extensions with a regular JSON file, the error messages will specifically mention it.

The features of RJSON are as followed.

Unquoted keys

If a property key is a valid identifier then the quotes can be omitted, just like in regular JavaScript.

{
  unquotedKey: true
}

Optional commas

Commas are not required to separate elements of an array or object properties.

Example

[
  1
  2
  3
]

{
  a: 1
  b: 2
  c: 3
}

Numeric separators

With the addition of numeric separators in JavaScript, support has been added in RJSON.

Example

5_000

Comments

Standard JS comments are supported. Both line and block comments.

The comment support also allows the manipulation of an RJSON file, while retaining comments.

Example

{
  // Line comment
  /* Block comment */
  foo: "bar"
}

Implicit top level object

Curly braces at the top level aren't required if it's just a list of properties.

Empty input is treated as an empty implicit object.

Example

foo: "bar"
"bar": "foo"

Add js-generator tests

ReferenceError: require is not defined when bundle client-side JavaScript

Description:

When the dependency uses require function, I got error

Uncaught ReferenceError: require is not defined

Generated code

const ___R$$priv$project$...$supports$color$index_js$os = require('os');

The bundle was created successfully but got error at runtime.

Steps To Reproduce

Error happen when depend project on axios module.

Expected Results

NodeJS API should be exclude from client-side bundle.

Update js-parser tests to match babel-parser

js-parser is a fork of babel-parser. The code has diverged way too far to allow any sort of commit merging but the test fixtures are still valuable. packages/@romejs/js-parser/__rtests__/__rfixtures__/ should be updated with those from babel-parser/test/fixtures and the numerous bugs fixed that they uncover.

Share Flow and TypeScript `import type` syntax

Flow supports this on import specifiers, not sure if TypeScript does so that may be the one exception to this.

Have been eagerly awaiting 😇

😏

Remove the use of non-inclusive terms

There is two non-inclusive words on master branch: 'whitelist' and 'blacklist'.
I think they are not inclusive and should be replaced by 'allow-list' and 'disallow-list' or some equivalent.

https://github.com/facebookexperimental/rome/blob/master/packages/%40romejs/js-compiler/transforms/compile/validation/optimizeImports.ts#L29
https://github.com/facebookexperimental/rome/blob/master/packages/%40romejs/js-parser/xhtmlEntities.ts#L273

Thanks

Create issues for all TODO comments

We have almost 100 TODO comments throughout the codebase. Go through these and work out what's still relevant and create issues for the rest. https://github.com/facebookexperimental/rome/search?q=TODO&unscoped_q=TODO

☂️ Governance

As the project matures we'll want to have a more established governance structure. This wont be an area of focus until a published release.

There is no node_modules folder in the .github folder

Hi :)

I was reading the Getting Started section in the contributing documentation.

In the below line mentioned about node_modules folder.

No dependency installation step is required as we check in our node_modules folder that contains only a copy of TypeScript and some definitions.

I clicked it but as you can see there is no .github folder. I think this is the new location of the node_modules folder.

Add Test262 for JavaScript parser

Prior art in this space:

https://github.com/babel/babel-test262-runner

Issues link in contributing page is broke

Description:

Issues link in contributing page is broke

Steps To Reproduce

1. Go to https://github.com/facebookexperimental/rome/blob/master/.github/CONTRIBUTING.md
2. Click on GitHub issues

Expected Results

Issues Page is open

Build from source?

Would love to help out with some documentation on building from source - if you can point me in the right direction I'm happy to make a PR 😄

Add ExportExternalDeclaration

Right now ExportNamedDeclaration is overloaded.

Update TS syntax

Since I implemented TypeScript support there has been new syntax added such as assert that I've yet to add.

☂️ Documentation

I think it makes sense to have an issue for documentation-related tasks since the website is up now. Here's a couple things I was thinking would be good to add as a start:

• Install and update instructions
• Getting started that uses rome init instead of echo - possibly a two tracks, one for new projects one for existing
• Command documentation within the command definitions themselves (packages/@romejs/core/master/commands)
• Add command docs and examples to website for all commands - if we can automatically pull from the command definitions that would be great
• Linting behavior - may want to hold off until this is finalized
• Usage with popular tools, ie React, Hapi

After writing the install and getting started, I'm thinking it makes sense to break the remaining up into a section of "Everyday Rome" which covers the most commonly used commands in depth with examples, a section of "Rome and Frameworks" which covers any framework-specific steps, and a section of "Rome Commands" which covers every option on every command, not necessarily with a ton of examples.

I'll try and work through some of these this week, but any help would be appreciated - if anyone has ideas on other things that would be valuable to add, that would be great!

Use Module.createRequire instead of Module.createRequireFromPath

Currently getting this Node deprecation message:

(node:2968) [DEP0130] DeprecationWarning: Module.createRequireFromPath() is deprecated. Use Module.createRequire() instead.

Can't parse ES6 imports *and* JSX in the same file

Description:

Consider the following file, which with various extensions doesn't parse.

/** @jsx mdx */
import {mdx} from '@mdx-js/preact';

export default function MDXContent() {
  return <h1>hi</h1>>;
}

When using .js:

> ./scripts/dev-rome parse test-file.js
 test-file.js:2 parse/js ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  ✖ import and export can only appear in a module

    1 │ /** @jsx mdx */
  > 2 │ import {mdx} from '@mdx-js/preact';
      │ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    3 │
    4 │ export default function MDXContent() {

  ℹ Change the extension to .mjs to turn this file into a module

  ℹ Add "type": "module" to your package.json

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

When using .mjs

> ./scripts/dev-rome parse test-file.mjs

test-file.mjs:5:9 parse/js ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  ✖ JSX syntax isn't enabled

    4 │ export default function MDXContent() {
  > 5 │   return <h1>hi</h1>>;
      │         ^
    6 │ }

  ℹ Are you using TypeScript? Change the file extension to .tsx

  ℹ Are you using Flow? Add a @flow comment annotation to the top of the file

  ℹ Not using either? Change the file extension to .jsx

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

✖ Found 1 problem

when using .jsx

./scripts/dev-rome parse test-file.jsx

test-file.jsx:2 parse/js ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  ✖ import and export can only appear in a module

    1 │ /** @jsx mdx */
  > 2 │ import {mdx} from '@mdx-js/preact';
      │ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    3 │
    4 │ export default function MDXContent() {

  ℹ Change the extension to .mjs to turn this file into a module

  ℹ Add "type": "module" to your package.json

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

✖ Found 1 problem

Steps To Reproduce

1. Put the contents of the file in a file named test-file with the appropriate extension from above (.js, .mjs, or .jsx).
2. run ./scripts/dev-rome parse test-file.jsx
3. one of the errors above appears

Expected Results

I expected it to be able to parse ES Modules without .mjs since this is supported by browsers. I didn't expect the .jsx extension to be relevant, although I can understand that. I expected that a file with ES Modules and JSX syntax would be parsed regardless of file extension.

Parser

The Rome parser is located at packages/@romejs/js-parser/. It was a fork of @babel/js-parser that has diverged so much it's almost indistinguishable.

Followed are some notes that may be useful.

• Plugins don't exist, they are hardcoded into the parser.
• The parser is tolerant, meaning that it will never throw runtime errors and will always produce an AST. This allows the parser to produce multiple diagnostics and potentially automatically fix small syntax errors.
• Plain functions are used instead of class methods on a long inheritance chain of Parser classes.
• See #3 for details on the diagnostic format.
• See #8 for details on the AST format.

DIsallow modifications when running lint without `fix`

This can currently trigger false negatives/positives.

☂️ Published Release

This issue is to track the milestone Published Release.

Rome is still in development and once we are confident we have something usable and stablefor a wider audience we'll publish to npm.

Where are the configuration options?

Playing with dev-rome a bit the documentation seems to only go one level deep; listing the commands that are available on ./scripts/dev-rome --help. Specific help for subcommands was not present and so I ran into 👇🏻 quite quickly.

Couldn't find a rome.json or rome.rjson or .rome.json or .rome.rjson for
    /my/cool/project/path

The following would be really helpful (to me, a totally random new user 😅):

1. A way to get docs for sub-commands
2. Some kind of indication of how to interact commands (./scripts/dev-rome config --help)
3. A pointer to config options and how to hydrate a new project

Seems relevant to #7

Markup

We have a package called string-markup that we process all strings through when we log to the console. This is also used inside of diagnostics strings. It's a HTML-like syntax that removes the need for hardcoding ANSI formatting, and would allow easy formatting in more rich environments like an IDE.

It looks like this:

Successfully formatted <number>5000</number> files

Compiled <emphasis><filelink filename="foo.ts" /></emphasis>

ANSI tags

Some possible tags are:

• inverse
• dim
• emphasis
• italic
• underline
• strike
• black
• brightBlack
• red
• brightRed
• green
• brightGreen
• yellow
• brightYellow
• blue
• brightBlue
• magenta
• brightMagenta
• cyan
• brightCyan
• white
• brightWhite
• bgBlack
• bgBrightBlack
• bgRed
• bgBrightRed
• bgGreen
• bgBrightGreen
• bgYellow
• bgBrightYellow
• bgBlue
• bgBrightBlue
• bgMagenta
• bgBrightMagenta
• bgCyan
• bgBrightCyan
• bgWhite
• bgBrightWhite

These map exactly to their typical ANSI formatting equivalent. In the future we might want to remove the color names in favor of aliases like primary, secondary etc and leaving it up to the formatter to decide colors.

Extensions

This becomes more powerful with abstractions like these that could be make richer in interactive environments:

number

Humanizes numbers

Example

<number>5000</number> -> 5_000

hyperlink

<hyperlink target="https://google.com">Google</hyperlink>

filelink

This is used to link to specific source file with an optional column and line.

In a terminal that supports hyperlinks it will be a clickable link that opens the file in the default editor.

When inner text is omitted a humanize version of target is used.

Example Error occured at <filelink target="foo.ts" column="5" line="10" /> -> Error occured at foo.ts:5:10

duration

Used for formating millisecond durations.

Example : <duration>5000</duration> -> 5s
Example: <duration approx>5000</duration> -> ~5s

filesize

Used for humanizing file sizes in bytes.

Example <filesize>5000</filesize> -> 5KB

Default attributes

If you have an existing tag you can avoid wrapping them in an emphasis or dim tag by just using it as an attribute.

Example Instead of <emphasis><filelink target="foo.ts" /></emphasis> you can use <filelink emphasis target="foo.ts" />

Developing on Windows?

Currently all of the scripts are written in bash which is possible to get working on WSL, but it may be a bridge too far for a lot of people. Maybe these scripts could be ported to Node?

The Roman Empire was a violent empire run by dictators

Description

Rome was the capital of the Roman Empire, a society run through ************, slavery and violence. Your etymological trivia refers to proverbs that seem innocent but refers to slavery and assimilation.

Sure you could argue about the technicalities of what you're actually referring to, but that's irrelevant. No matter your intensions, the profile of this project is of white ruling and conquest. You can pick a much better one, one that isn't offending or reeks of white peoples' historical ignorance, one that conveys union, cooperation and solidarity rather than wartime colonialism and oppression.

Steps To Reproduce

Rename this to something that refers to American slavery and ask for feedback.

Expected Results

Outrage.

AST

The Rome AST is derived from estree but with some pretty significant changes. Contained here are notes that may be useful when working with it.

• Redundant AST nodes have been eliminated. Some of these exist in estree to provide additional location information eg. ClassBody but it has been eliminated in favor of putting the body array on the parent.

• The entire AST is fully strongly typed and type definitions can be found in packages/@romejs/js-ast/ . This makes it relatively easy to follow and will exist as canonical documentation.

• Flow and TypeScript nodes are prefixed with namespaces.

• Effort has been made to reduce ambiguity in the AST, ie. Identifier has been split into AssignmentIdentifier, BindingIdentifier and ReferenceIdentifier.

• If multiple AST node types share properties then it's been abstracted into another node. For example, ClassExpression and ClassDeclaration both have a ClassHead property. This makes it easy to convert between the two by just retaining the head.

• This is more notable with PatternMeta which is set on pattern node types.

• Object keys have a dedicated node in the form of ComputedPropertyKey and StaticPropertyKey. These are shared amongst ObjectProperty, ClassMethod etc. This makes it very easy to share logic.

• Similarly, MemberExpression has a ComputedMemberProperty and StaticMemberProperty property.

Codebase structure

☂️ Integrations

This issue documents possible Rome integrations into existing tools.

This will be limited by the public API discussed in #10, notably async only methods that may restrict integration in some tooling.

removing node_modules

as node_modules is from history I don't think creating PR is easy . However I think we should add node_modules to gitignore ?

I used the following command to remove entire node modules from git history

find . -name node_modules -print0 | xargs -0 git rm -rf --ignore-unmatch

I did made a fork which address this issue.
https://github.com/shirshak55/rome/

I think pushing node_module is not intentional right?

☂️ Website

I've yet to start building any sort of website. I'd love for someone else to start building one as it will definitely be needed for our first release.

Improve README

Please describe the actual usage of the package

Its amazing how there can be such a long readme file and it still does not communicate what this actually does...
— https://news.ycombinator.com/item?id=22430940

What's the best way for a new contributor to this project to get involved?

Congrats on Rome! A lot of people are excited about this project and some people are itching to get involved. There are already a lot of issues in the issue tracker and there are clearly laid out philosophies, etc. Seems like fertile ground for folks to contribute.

It would be great if layered on top of the good work here if there was some signal about areas you're specifically looking for active help on from people who are eager to contribute but haven't yet consumed the roadmap. Perhaps you have it already and I haven't looked closely enough.

What is best way to get outside contributors involved? And what specifically are y'all looking for contributions to currently that aren't already assigned to the existing team?

Package manager

There's a plan to make Rome a package manager too? This way the only external dependency would be the Node itself.

Projects

The package @romejs/project is responsible for loading, validating, and normalizing project configs. Rome project config exist as rome.json or rome.rjson files. It can also take the form of a rome property in package.json.

Diagnostics

Diagnostics are an extremely powerful feature of Rome that allow the generic construction and presentation of errors in source code.

• Types can be found in packages/@romejs/diagnostics/types.ts.
• Diagnostics can take two forms. The PartialDiagnostic type, which has a lot of optional properties and allows building up diagnostics in a more raw manner. The Diagnostic type has required properties that during normalization from PartialDiagnostic are inferred if necessary. This format is what is exposed to consumers and formatting logic.
• The package @romejs/diagnostics contains the type definitions, normalization logic, and other utilities.
• The package @romejs/cli-diagnostics contains the terminal formatting logic.

Server architecture

Update vendored version of Rome

Implement ESLint rules

Followed is a list of ESLint rules that we should implement.

• enforce return statements in getters (getter-return) #129
• disallow using an async function as a Promise executor (no-async-promise-executor) #101
• disallow comparing against -0 (no-compare-neg-zero) #106
• disallow assignment operators in conditional expressions (no-cond-assign) #116
• disallow the use of debugger (no-debugger) #103
• disallow duplicate arguments in function definitions (no-dupe-args) #99
• disallow duplicate keys in object literals (no-dupe-keys) #98
• disallow a duplicate case label (no-duplicate-case) #100
• disallow empty character classes in regular expressions (no-empty-character-class) #135
• disallow reassigning exceptions in catch clauses (no-ex-assign) @weblancaster
• disallow unnecessary boolean casts (no-extra-boolean-cast) @zinyando
• disallow reassigning function declarations (no-func-assign) #130
• disallow assigning to imported bindings (no-import-assign) #118
• disallow variable or function declarations in nested blocks (no-inner-declarations) @tatchi
• disallow invalid regular expression strings in RegExp constructors (no-invalid-regexp) @KevinKelbie
• disallow multiple spaces in regular expression literals (no-regex-spaces) #121
• disallow returning values from setters (no-setter-return) @torifat
• disallow sparse arrays (no-sparse-arrays) #91
• disallow unreachable code after return, throw, continue, and break statements (no-unreachable) @JayaKrishnaNamburu
• disallow control flow statements in finally blocks (no-unsafe-finally) #117
• disallow negating the left operand of relational operators (no-unsafe-negation) #89
• disallow template literal placeholder syntax in regular strings (no-template-curly-in-string) #112
• disallow deleting variables (no-delete-var) #95
• disallow labels that are variable names (no-label-var) #102
• disallow shadowing of restricted names (no-shadow-restricted-names) @MattsJones
• suggest template literals instead of string concatenation (prefer-template) #138
• (disallow-var) #107

Please comment if you want to work on one of these and I'll mark you to avoid duplicating work. Mentions next to rules indicate that someone else is working on it. If a PR isn't opened within a few days then it will be up for grabs.

A checkmark indicates an open PR.

Fatal error occurred: Error: EMFILE: too many open files

Description:

OSX 10.15.1
Node v12.14.1

Tried to follow the steps in CONTRIBUTING.md but keep running into a too many open files error.

I see the Adding project /... line for about a second and then the error pops up.

Steps To Reproduce

1. Cloned the repo

❯ git clone [email protected]:facebookexperimental/rome.git
Cloning into 'rome'...
...
Updating files: 100% (8958/8958), done.

❯ cd rome

2. Ran the help command

❯ scripts/dev-rome --help
⚠ Disk caching has been disabled due to the ROME_CACHE=0 environment variable ⚠
✖ Fatal error occurred: Error: EMFILE: too many open files, watch
  at
  FSEvent.onchange (internal/fs/watchers.js:123:27)
internal/modules/cjs/loader.js:796
    throw err;
    ^

Error: Cannot find module '/tmp/rome-dev/index.js'
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:793:17)
    at Function.Module._load (internal/modules/cjs/loader.js:686:27)
    at Function.Module.runMain (internal/modules/cjs/loader.js:1043:10)
    at internal/main/run_main_module.js:17:11 {
  code: 'MODULE_NOT_FOUND',
  requireStack: []
}

3. Tried again with ROME_CACHE=1

❯ ROME_CACHE=1 scripts/dev-rome --help
⚠ Disk caching has been disabled due to the ROME_CACHE=0 environment variable ⚠
✖ Fatal error occurred: Error: EMFILE: too many open files, watch
  at
  FSEvent.onchange (internal/fs/watchers.js:123:27)
internal/modules/cjs/loader.js:796
    throw err;
    ^

Error: Cannot find module '/tmp/rome-dev/index.js'
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:793:17)
    at Function.Module._load (internal/modules/cjs/loader.js:686:27)
    at Function.Module.runMain (internal/modules/cjs/loader.js:1043:10)
    at internal/main/run_main_module.js:17:11 {
  code: 'MODULE_NOT_FOUND',
  requireStack: []
}

4. Same with build-release

❯ ./scripts/build-release dist
⚠ Disk caching has been disabled due to the ROME_CACHE=0 environment variable ⚠
✖ Fatal error occurred: Error: EMFILE: too many open files, watch
  at
  FSEvent.onchange (internal/fs/watchers.js:123:27)
internal/modules/cjs/loader.js:796
    throw err;
    ^

Error: Cannot find module '/tmp/rome-dev/index.js'
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:793:17)
    at Function.Module._load (internal/modules/cjs/loader.js:686:27)
    at Function.Module.runMain (internal/modules/cjs/loader.js:1043:10)
    at internal/main/run_main_module.js:17:11 {
  code: 'MODULE_NOT_FOUND',
  requireStack: []
}

Expected Results

Expected to see rome help

Unable to enable linting

Hello! I have created a new project and added rome as a dependency. Here's my package.json:

{
  "name": "myproject",
  "version": "1.0.0",
  "description": "",
  "main": "src/index.js",
  "scripts": {
    "rome": "node ./node_modules/rome/bin/rome"
  },
  "author": "rzig",
  "license": "ISC",
  "devDependencies": {
    "rome": "file:../rome/dist"
  }
}

The file in src/index.js is just one line, console.log("Hi");.

I am able to successfully run npm run rome compile src/index.js, but running npm run rome config enable lint fails with the following:

✔ Setting lint to true in the project config rome.json
✖ Error occured while testing new project config. Your changes have not been saved.

 rome.json:2:10 json ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  ✖ Expected object at lint

    1 │ {
  > 2 │   "lint": true
      │           ^^^^ 
    3 │ }

 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

When I manually update rome.json and run npm run rome lint src/index.js, I get

rome.json:2:12 json  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  ✖ Expected object at lint

    1 │ {
  > 2 │     "lint": true
      │             ^^^^ 
    3 │ }

 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

I'm guessing the reason that the second step of rome config enable lint fails is because rome is setting lint to true when it should actually be an object?