rome: A fully self-contained experimental javascript toolchain

栏目: IT技术 · 发布时间: 4年前

内容简介:Romeis an experimental JavaScript toolchain. It includes a compiler, linter, formatter, bundler, testing framework and more. It aims to be a comprehensive tool for anything related to the processing of JavaScript source code.Romeis not a collection of exis

rome: A fully self-contained experimental javascript toolchain

Romeis an experimental JavaScript toolchain. It includes a compiler, linter, formatter, bundler, testing framework and more. It aims to be a comprehensive tool for anything related to the processing of JavaScript source code.

Romeis not a collection of existing tools. All components are custom and use no third-party dependencies.

Romeis experimental and in active development. It's open for contributors and those interested in experimental tools. It is not ready for production usage. The only way to use it is to build from source.

Romeaims to be a replacement for many existing JavaScript tools. We will, however, offer integrations for components in other tools. For example, using the Rome compiler as a plugin for another bundler.

Romeis MIT licensed , and the project managed under the Contributor Covenant Code of Conduct .

History

Romewas started by Sebastian McKenzie , the author of Babel and Yarn .

Romeis a project from the React Native team at Facebook.

Romegets its name from proverbs such as "All Roads Lead to Rome", "Rome wasn't built in a day" and "When in Rome, do as the Romans do". This refers to the expansive scope and the desire for conformity across the project. It started as a joke at the office.

Romehas a logo of an ancient Greek spartan helmet. It's not very relevant since it's not Roman, but it looks cooler than a Galea .

Codebase

Romeis written completely in TypeScript with sparing usage of loose types.

Romeis a monorepo with internal packages to delineate code boundaries.

Romeis self-hosted and compiles itself with an old version.

Romesupports processing JSX as well as Flow and TypeScript annotated code.

See CONTRIBUTING for more information.

Status

The current area of focus is linting . See the umbrella task #20 for tracking.

Philosophy

This list includes general ethos the project should abide by. This list is not comprehensive. Some of these are obvious but are stated for completeness.

Project Management

  • Set clear expectations. Make project intent and decisions known well in advance. Nothing should be a surprise.
  • Transparency. No back-channel project management. Project conversation and decisions will take place only on public forums such as GitHub, the Rome Discord, and Twitter. The only exception to this is moderation decisions which will be strictly done in private.

Technical

  • No external dependencies. This allows us to develop faster and provide a more cohesive experience by integrating internal libraries more tightly and sharing concepts and abstractions. There always exist opportunities to have a better experience by having something purpose-built.
  • Errors should suggest fixes and hints where possible. These should be inferred and filtered from usage to reduce surfacing irrelevant and unhelpful messages.
  • Unique and specific error messages. No generic error messages. This not only helps users understand what went wrong, but should provide maintainers with a unique call site and the necessary information to debug.
  • Minimize API. Question the existence of all options and flags. Are they necessary? Can they be combined? How can we reduce code branching?
  • Reduce jargon. Don't assume that users will understand specific terminology. Strive to provide clear meaning for experts and beginners. For example, use "character" where you would traditionally use "token" when producing parser errors.
  • Utilize verbosity when naming commands and flags. No unnecessary and confusing abbreviations.
  • Use inclusive terminology. Use gender-neutral pronouns. No ableist slurs. No usage of terms that could be considered insensitive.
  • Build for generic clients. Don't assume that output will only be consumed by a terminal and using ANSI codes. Use abstractions that could be generalized for viewing in an IDE, browser, or other environments.
  • Use strong types. Don't use loose types such as any . Where possible, refine and validate input. Aim for sound types.
  • Terminal output should be unambiguous. When designing terminal output, don't purely rely on formatting cues such as color. Always use a combination of formatting, symbols, and spacing. If all ANSI codes are striped, all the output should still be understood.

Community

Additional project coordination and realtime discussion happens on our Discord server . Remember that all activity on the Discord is still moderated and will be strictly enforced under the project's Code of Conduct .


以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

大数据时代的IT架构设计

大数据时代的IT架构设计

IT架构设计研究组 / 电子工业出版社 / 2014-4 / 49.00元

《大数据时代的IT架构设计》以大数据时代为背景,邀请著名企业中的一线架构师,结合工作中的实际案例展开与架构相关的讨论。《大数据时代的IT架构设计》作者来自互联网、教育、传统行业等领域,分享的案例极其实用,代表了该领域较先进的架构。无论你就职于哪一行业都可以从本书中找到相关的架构经验,对您在今后的架构设计工作中都能起到很好的帮助作用。 《大数据时代的IT架构设计》适合具备一定架构基础和架构经验......一起来看看 《大数据时代的IT架构设计》 这本书的介绍吧!

在线进制转换器
在线进制转换器

各进制数互转换器

XML 在线格式化
XML 在线格式化

在线 XML 格式化压缩工具

RGB CMYK 转换工具
RGB CMYK 转换工具

RGB CMYK 互转工具