sebastianmck

I explicitly state 2020. Activity picked up in March. Use GitHub search filters and it’s more apparent.

Activity graphs can be deceiving, it’s extremely easy to look busy. Actually drill down and you’ll notice a lot of the activity earlier in this year was just pull request approvals, without comment, mostly done after someone else had already approved.

The Rome license will stay MIT.

I've been keeping the core contributor team updated on the funding process since December. We've also been publicly speaking about it in the Rome Discord server too. I posted about securing funding in early April in #general.

Emanuele and Yasser both approached us during this period to offer their interest in joining and have stayed actively involved in development.

It's a good question around how to compensate the shoulders of the giants you're standing on, and I don't think anyone has a good answer for that. I think it's important to note that the credits page is meant to be as exhaustive as possible. I am not aware of many other projects that have something similar, and theirs are likely to be even longer.

In the end the community is getting value because we'll now be able to do more to improve the project than we otherwise would have. Babel most notably has struggled for funding and is even currently undergoing a serious funding shortage. It has been used as one of the poster children for the JS community and it's clear that donation-based funding isn't effective, at least on the order of magnitude required to support a team.

Supplemental services that integrate with the tool. Think code quality monitoring, error reporting, and core enhancements like a remote cache. There's a lot we're going to be experimenting with.

Previous HN discussion: https://news.ycombinator.com/item?id=24094377 (first release) and https://news.ycombinator.com/item?id=22430682 (open source)

Nothing has materially changed since the release announcement.

TypeScript is a frontend language. "Frontend" is the category of languages we plan on supporting. It doesn't say anything about your usage of those languages. Where you run the code does not matter.

Depends on what it is I think. We discussed the idea of "expansion packs" which would enable certain funtionality as a sort of "limited config" hack. https://github.com/romefrontend/rome/issues/173

I specifically call out not allowing smaller communities to grow that don't have the advantage of their community size being forcing functions for support. It's the most compelling reason to me to even have any sort of plugin or custom rules system in the first place.

Although we didn't go through with that idea because they can just be enabled by default since the patterns they're linting for are unambiguous, I guess that applies to any additional ones, although so far the way we've approved these sort of these has been adhoc. There's a strong desire though to formalize some "approval process" for lint rules and more typical project decisions.

It's both.

Thanks! Yeah, it is, at least for a while since it will take a very long time to reach expected maturity. You can adopt as many or as little pieces as you want. The idea is that once you adopt one of the "tools", you can use the others and reuse the exact same configuration, and ideally you shouldn't even need to do anything else.

ie. For linting we also do dependency verification. So you might need to configure Rome if you put your dependencies on some weird non-standard place. Once we open bundling up, we'll already know how to resolve everything.

Each part should stand on it's own. It's not as if the linter we've released is worse, and the only selling point is that it's going to be part of a larger suite. It legitimately has features and separates itself from the alternatives. eg. extreme focus on useful error messages, powerful autofixes (that operate on an AST rather than insert strings like ESLint), proper caching for even better performance (ESLint doesn't offer a good solution here) etc.

Many are making the mistake in thinking that building Rome is just as time consuming and resource intensive as rewriting each of the tools it's meant to replace separately, it's not. Once we've validated the linter we've also validated the compiler (it's the same thing), our ability to watch files, analyze dependencies, integrate with your editor etc. Sharing so much fundamentally decreases the actual complexity of everything, not increases.

I think it's also important to note that I personally have written an extremely small amount of the implemented lint rules. Our API is just easier to use, and we've focused on setting up the tooling necessary to make writing them easy (although internally in our repo).

Check out https://github.com/romejs/rome/issues/341, https://github.com/romefrontend/rome/issues/20, and https://github.com/romefrontend/rome/issues/159, if you're interested in seeing how the progress was actually made in the implementation of those rules. The work was spread out over a really long time, and if given complete focus and proper coordination (I was not good at this and kind of let it be organized ad-hoc, which is actually how we got some amazing contributors), then it could have been completed in a fraction of the time.

There's been some overfocus on particular things like minimal configuration and the lack of extensibility but those are not hard requirements and will evolve over time, particularly as we get feedback and people demonstrate the requirements and restrictions they're under. The project understandably involves a lot of hubris, but I do believe that Rome isn't only valuable in aggregate and will have significant advantages even if you only decide to use one piece.

It's a linter so you don't need to ask any of those questions. Future usage as a bundler isn't dependent on any decision to use it as a linter.

I spoke in this post about how rushing into a plugin system hurt the longevity of Babel and it's ability to innovate. We aren't going to make the same mistake again. Rome will likely eventually have a plugin system, but what that would look like isn't clear.

This is the first release and until there's some actual usage, there's no real way to realistically predict what sort of things people will feel is missing. You can always supplement your project with multiple linters if you feel like it is currently a blocker.

The ecosystem is already fragmented and dueling. When it says it replaces those tools it means it aims to replace the functionality of those tools, not make them obsolete.

Rome being successful doesn't mean eliminating those tools, it's providing something valuable and giving people an option. If it's not for you then that's okay. Rome is early and is still evolving, including possible areas for extensibility.

I think a lot of people don't realize the sort of capabilities that they're missing out on by not having their tools work together, or sticking with old tooling that cannot innovate for legacy reasons (like Babel). I don't think it's harmful to the ecosystem to advocate for more consolidation, especially around tooling that not a lot of people either like to deal with, or have few maintainers in the first place.

I also think you have me (Sebastian McKenzie) confused with Sebastian Markbage from the React team.

It does. And it's a risk not keeping up with their pace of development. Supporting those "compilers" is just supporting their syntax, which both fortunately already have very good compliance test suites because other tools like Babel already reimplement their syntax anyway.

The claim of no dependencies isn't there as some grandiose statement about reduction of complexity, it's there to describe how self contained the project is and our ability to change things. I'm going to refer to a comment I already made elsewhere in this thread:

> Considering this is just a source code dump and call for possible contributors I'm disappointed it was even posted to Hacker News. Rome is not ready at all for public consumption. I wanted it open sourced so I could work with other tooling authors and contributors.

Those things you are asking will come at a time when Rome is actively being marketed as a tool for users rather than an experimental project for contributors.

The TypeScript type checker is only used to type check the Rome source code. The compiler is not used at all.

Considering this is just a source code dump and call for possible contributors I'm disappointed it was even posted to Hacker News. Rome is not ready at all for public consumption. I wanted it open sourced so I could work with other tooling authors and contributors.

> Why would they hide their commit history?

I'm the only author at the moment. The project started off years ago as a side project without any commit history, and what little history there was over the years wasn't very thorough. Prior to the open sourcing I've been working on it internally and still did pretty massive diffs that changed thousands of files, still without good history. It's something I'm working on though and will obviously need to be accountable for now that the project is public.

I'm skeptical too (I'm the author of Rome). I know it can be at least performance neutral compared to existing JavaScript tools which is the baseline for most people. However I do think that since Rome is an enclosed system, without external dependencies and pretty good TS typing, that there's some future flexibility using another wasm language that other JS tools don't have.

See the fourth paragraph.

> This shift naturally raises questions about the rest of Facebook's open source projects. Many of our popular projects will keep the BSD + Patents license for now. We're evaluating those projects' licenses too, but each project is different and alternative licensing options will depend on a variety of factors.

Hey! I'm Sebastian McKenzie (@kittens on GitHub) and I'm the lead develop on Yarn at Facebook. We initially used a method similar to ied when we first started experimenting with internal usage at Facebook.

We ran into a lot of issues with OS compatibility around symlinks and existing tools not supporting it. Windows lacks support for symlinks on non-Admin accounts, NTFS junctions work but they're slightly quirky in their behaviour and don't behave exactly the same way.

A lot of tooling relies on the existing node_modules structure. ESLint for example will load tools relative to itself which means that they need to be reachable in the tree, you can solve this with hardlinks but there's caveats with that too. Existing tools aren't very well suited for handling cycles either which in a system like npm are extremely common as a transitive module could depend on one that's higher in the graph.

We care a lot about existing ecosystem compatibility and because of these limitations we went with the current status quo. We'll continue to explore others options though and if there's a chance we can do it without any of these caveats then we're more than happy to explore it.

Let me know if you have any further questions!

Hey, I'm 18 and currently work fulltime at Facebook in London. I can definently relate to some of the things you touched on, feel free to reach out if you'd like to have a chat. Email should be in my profile.

Babel actually supports flow type annotations and declarators will be available once there's a decent ES7 spec for them.

See https://github.com/babel/babel/issues/568 for why this name change happened.

Not really true. Babel is a generic term for translation/languages and the Python and JavaScript world are very different so confusion about a translation library and a JavaScript transpiler is extremely unlikely.

Haven't finished the rename yet.

Available as of 3.5.0. Happy to answer any questions if anyone has any!