sebastianmck
Joined 14 years ago
Karma
853
Submissions
62
Member since
Mar 23
[email protected]
View on Hacker NewsRecent submissions
Comment · 4 years ago
Comment · 5 years ago
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.
Comment · 5 years ago
The Rome license will stay MIT.
Comment · 5 years ago
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.
Comment · 5 years ago
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.
Comment · 6 years ago
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.
Comment · 6 years ago
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.
Comment · 6 years ago
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.
Comment · 6 years ago
It's both.
Comment · 6 years ago
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.
Comment · 6 years ago
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.
Comment · 6 years ago
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.