13 ms·
Rome v12.1: a linter formatter for TypeScript, JSX and JSON
- throwaway81523 3y agoWhy write something like this in Rust since it presumably doesn't have anything memory intensive or real time going on? Rust's manual memory management is a necessary thing sometimes, but it is a pain, right?
- TobyTheDog123 3y agoHa - I was thinking the exact opposite. I'd have figured that tools that require an understanding of an entire project (imports/exports/types/etc) would need be VERY memory intensive, and something that would actually benefit from manual management/rust. I don't know much about compilers/formatters/linkers and how they work though, so I could easily be wrong.
- throwaway81523 3y agoNah at worst it's like a compiler. Memory intensive = browser engine that is going to burn gigabytes. That was the original use case for Rust.
- galangalalgol 3y agoCompilers are very memory hungry.
- throwaway81523 3y agoYou can write a memory hungry compiler but you don't have to.
- postalrat 3y agoFreeing up memory has a cost and if you don't need to do it then don't. And if you don't need to free up memory you can't have a memory leak.
- throwaway81523 3y agoIf you aren't short of memory, why write in a language designed around managing it? The alternative is garbage collection, not simply leaking it.
- postalrat 3y agoYou can write an application that never frees memory and isn't leaking memory.
- throwaway81523 3y agoFor some embedded applications, fixed memory regions work fine. For something like a compiler, not so much. Remember that you have to deal with chunks of data of unpredictable size. Even string literals might occupy megabytes. You could program your way around that, but most of the time these days, it's ok to burn memory (i.e. use GC) for the sake of development velocity.
- timeon 3y ago> but it is a pain, right? Not really.
- thotthinkr 3y agoI look at tools like Rome and they might have been relevant 5 years ago. I think Bun has a better shot than Deno because it has a very fast built in node_modules installer. But I think Bun's goals are too ambitious - trying to be all things to all projects from a single binary. No one cares if you have to use a separate binary, esbuild, for all your bundling needs, for example. It's amusing how the entire JS ecosystem put up with such slow build times for a decade. If these JS tools teach us anything it's that JavaScript doesn't cut it for performance and a compiled language is the way to go.
- samsquire 3y agoMy guess is that IO latency is the reason why Javascript tools are slow. Creating lots of separate TCP connections to download a tarball and then store it to disk, then decompress it and then write the files it contains. Lots of small files IO slows things down versus one large contiguous file transfer. If it is IO that is causing slow project builds, then the IO in theory would be slow with compiled tools as well.
- conaclos 3y agoBun do not plan to implement a formatter or a linter. This makes Rome and others still relevant.
- veidr 3y agoI don't get your central point. What is different about now compared to 5 years ago, when it comes to a code linter and/or bundler? At first glance, I thought you were saying "this Rome thing might have been relevant 5 years ago, but now Bun and Deno exist, so it is not." But, that didn't really make sense because Bun and Deno are both new and growing and there's no clear winner, or even leader, in the "post-NodeJS runtimey programming thingamajig and excution environment". Re-reading your comment, though, it seems like what you are really saying is "JavaScript itself is slow, so it is no longer relevant". But when stated so plainly that sentiment becomes absurd, so as a reader I sort of mentally revise my interpretation of it to "JavaScript is slow (yes), so I personally wish people would just switch to faster languages". But that doesn't really make sense in this context, either, because this tool is written in Rust. So... what are you saying? What thot r u the thinkr of here?
- veidr 3y agoI click through every formatter-related post because I am looking for something better than what I have. My team at work wanted to use Prettier, but lack of configurability (and also heinous bugs!) made me switch to dprint[1]. But even dprint doesn't do a couple of the things I want, #1 of which is "For the love of science, please stop deleting the intentionally placed blank line after a hugely long class declaration!" E.g.: @Directive() export abstract class AutocompleteComponentBase<T> implements ControlValueAccessor, AfterContentInit, OnDestroy { @ViewChild(DsAutocompleteContainerDirective, { static: true }) autocomplete: DsAutocompleteContainerDirective<T>; // class definition continues... I mean, I know I am a bad person because of those long names, but that is how life goes sometimes! And the blank line there at the top is just very important to like, catch one's breath, while reading this code. (I'm really just posting this in the hopes that somebody will throw me a "Bro, just use hpstrlnt, it totally lets you configure that!" -- I have not actually tried Rome to see if it does (it's Monday morning and I'm not quite ready to be disappointed again...)) [1]: dprint is good, and I recommend it as the best code formatter I currently know of: https://dprint.dev/ https://dprint.dev/
- conaclos 3y agoThis new version adds the support for Stage 3 decorators. It also stabilizes more than 30 linter rules.
- jordn 3y agoIs this good/stable now? Worth switching from Pettier and eslint?
- iends 3y agoIt links against a more recent glibc than Amazon Linux supports, so in my case it’s not ready for usage on EC2 hosted CI machines.
- ovao 3y agoThe tooling itself is in relatively good shape in my usage, although the VS Code extension currently has a number of rough edges (frequent crashes, etc.). It’s worth a try, but wouldn’t necessarily recommend ‘switching’ wholesale at the moment.
- xctr94 3y agoI suppose it’s “JS-stable”, given it is version 12, cutting 2 majors in 6 months.
- Waterluvian 3y ago“Pettier” whether a typo or not is hilarious and apt. And I’m not even being insulting. I love how petty it is. :)
- white_dragon88 3y ago[dead]
- forty 3y agoDoes it allow to create local custom lint rules? I haven't found anything about this in the doc
- progx 3y agoRome has not much rules, that is their philosophy, you should not waste much time with every single configuration option and use it as it is. https://docs.rome.tools/lint/rules/ https://docs.rome.tools/lint/rules/
- forty 3y agoOk, not having much rules is fine, but not allowing me to create my is really a downside compared to eslint. Creating arbitrary static checks is really super powerful and actually useful to overcome limitations of what can be done only with TS typing.
- eberkund 3y agoDoes this work with Vue SFCs?
- whatever3 3y agoDoes anyone know what has happened to the company behind Rome? Seems like all the employees have left
- sfobiab 3y agoWhat I have heard and seems was considered "common knowledge" about a year ago was that the founder embezzled the money. His VCs considered suing, but decided it was just too messy. I'm not joking, something about some seriously extravagant vacations and a house renovation all paid right out of the company's bank account.
- habitue 3y agoAny links to direct discussion of this (or sources)? All I can find is indirect evidence that they burned through vc money too fast
- norman784 3y agoAFAIK they ran out of money and now the project is community driven, so no hopes to have the all in one tool soon
- nindalf 3y agoYou have a source for that? Couldn't find a mention on their blog.
- norman784 3y agoIs not an official source, but it seems that it is the case according to this discussion[0], searching in the social media accounts there's nothing, also Sebastian[1] didn't published anything more about Rome since December [0] https://github.com/rome/tools/discussions/4302 https://github.com/rome/tools/discussions/4302 [1] https://twitter.com/sebmck https://twitter.com/sebmck
- 3y ago
- cabirum 3y agoV12? When/how did they jump from v0.x.y to 12?
- k__ 3y agoProbably like React. 0.10.0 0.11.0 12.0.0
- VPenkov 3y agoMakes sense. In 0.x.y releases, any version changes are allowed to have backwards-incompatible changes. Authors typically use "minor" version changes to indicate this. https://semver.org/#spec-item-4 https://semver.org/#spec-item-4
- capableweb 3y agoIn what way does it make sense from going from 0.16.0 to 17.0.0? First stable release would be 1.0.0 if you want it to make sense somehow. Or are we just starting at whatever versions we want now? My next library is gonna start at 666.0.0 once it gets stable in that case.
- detaro 3y agoIt's not exactly unusual to go to non-zero major versions that way, especially if it's been at 0.x for a while and people are thinking/talking about those versions. No confusion between 0.16 and 1.6 etc.
- vinnymac 3y agoSeems fruitless as an approach to reducing confusion to me. What about versions 0.1.6, 0.6.1, 6.0.1, and 6.1.0? I’d be more likely to think something was wrong with those releases, and assume someone was forced to delist versions 0.16.0 thru 1.5.0.
- plugin-baby 3y ago
- k__ 3y agoHalf-OT: What do you think of pnpm? I saw it off and on since 2015 and read some projects switched to it and then back again, when it didn't work out.
- johnnypangs 3y agoComing from using yarn, it is way easier to move to pnpm than to yarn 2+. It’s now my go to. The only issues I find is that you’ll still not find good community support for it. Things like Dependabot and some edge hosting platform build agents.
- hammeiam 3y agoYou can email the dependabot team and they'll opt your repo into a beta with pnpm support
- nwienert 3y agoDon't think this is true, yarn 2 is a drop in basically you may be thinking of the PnP stuff but that's off by default now. pnpm used to be the difficult one but seems a bit better these days.
- xiphias2 3y agoFor me there was always problem with pnpm cache working together with vite when doing pnpm link, and yarn link works perfectly, so even though pnpm is much faster, I went back to yarn.
- progx 3y agopnpm has only benefits if you use it with packages / workspaces and things like automatic patching. Use it in some projects, but for the most simplier projects i stay with simple npm and use scripts (via scripty). Install / update perfomance or SSD space saving are for me not really killer features.
- mikojan 3y agoFrom personal experience introducing pnpm into a big JavaScript project my very subjective(!) view of the situation: pnpm offers fast installs and the best dependency management capabilities I have seen. However, there is a steep learning-curve attached to the latter. You cannot just task a random developer with fixing emerging problems or else you will be left with half-a-dozen large and unintelligible config files and hacks. If you are the type of team that never updates dependencies, it is not worth the effort. If you are the type of team that applies the heuristic of "yes" to the question "Should I download a dependency?", it is not worth the effort. On the other hand, if you value build tool performance, if you are updating frequently and if your dependencies are carefully curated, pnpm is great and with Node >16 it is just a... $ corepack enable ...away, too.
- Raed667 3y agoEslint can get VERY slow on large apps. Rome seems to be the perfect answer to that, but I can't seem to find a way to port/import Eslint rules into Rome.
- vlovich123 3y agoThat’s because it only supports a very small subset of lint rules. As best I can tell, the rules are very opinionated often in weird ways and not particularly as complete as ESLint.
- Raed667 3y agoThanks for the clarification. So it is basically only suitable for greenfield projects?
- progx 3y agoIt works as it should, as a user you have to accept that rome works in a specific way. If you can do that and live with that, rome is a excellent tool. It took me some weeks to accept the "rome way" and now i am more than happy with that and did not waste time with endless configurations of eslint/prettier.
- Raed667 3y agoWhen you have a large project with +500k lines of code, two dozen contributors, tens of eslint rules, it is very hard to "just" do it the rome way. A migration path is required, otherwise you'll introduce a tool, have a PR that reformats everything and it will be a huge mess.
- conaclos 3y agoRome is less opinionated than it used to be. However, I admit it is still more opinionated than ESLint. It is part of its ADN. However, Rome is also trying to provide a smooth experience. And we are open to relax some rules if it makes sense. If you have some time, we would like to get to know the rough edges of Rome.
- vsskanth 3y agoIs there a JSON formatter out there that can be configured specifically for numeric arrays ? I'm specifically looking for something that formats 1D arrays in one line and 2D as one line per row. fracturedJSON gets close but not exactly what I want.
- andrewmcwatters 3y agoI've got mixed feelings about Rome. There's so much room to cover with ridiculously slow tools today. But I'm sick and tired of these people in the industry dropping their toys because they're tired of working on stuff people actually use instead of just improving what they currently have. Would it have been impossible to nudge Node.js in the direction of where Deno is today? Would it have been impossible to replace Babel with a Go implementation? I also don't want tools that want to be literally everything. Imagine if Daniel Stenberg was like, "You know what I'm tired of cURL, let me rebuild literally the same thing in another language and give it a new name, and entirely different opts."
- badrequest 3y agoThere's this incredible phenomenon on this website where someone posts "Show HN: <tool>, but modern" where <tool> is something used by nearly every Linux machine in the last 40 years, and what makes it "modern" is Rust, inexplicably.
- scns 3y agoHow much time do you spend improving those tools you use? Honest question , zero snark intended.
- jupp0r 3y agoWho knows if curl would have ever existed if Stenberg would have invested his time in improving existing tools.
- muglug 3y agocURL is written in C, and also (definitionally) IO-bound so the benefits of rewriting aren’t obvious perf-wise. JS linters running in Node are mostly CPU-bound. You can get an order-of-magnitude improvement from writing those tools in Rust.
- andrewmcwatters 3y agoThis is being pedantic. That's not the point: do you have to literally abandon the project instead of rewriting it and leaving all your users out to dry? Would you get divorced from your spouse if something minor wasn't working out, too?
- Destiner 3y agoI don't see how they are going to compete with tons of ESLint plugins. There's just no way a small team can do such a large amount of maintenance.
- Timon3 3y agoThis seems to have worked for Ruff in the Python world: https://github.com/charliermarsh/ruff https://github.com/charliermarsh/ruff It re-implements a bunch of popular linting rulesets & plugins in Rust and is incredibly fast, especially compared to the other tools.
- qudat 3y agoYou want to know how it competes? “yarn add rome” Done. Now demonstrate the equivalent using prettier, eslint, and typescript. It’s a configuration nightmare …
- mock-possum 3y ago‘npm init @eslint/config’
- qudat 3y agoAs far as I can tell that doesn't include prettier which is an annoying configuration since eslint and prettier partially overlap in feature-set
- mock-possum 3y agoThat is true. It’s easier to get ESLint and prettier running together than it uses to be, but it is still a bit of a hassle. Prettier needs to be added as an ESLint plugin, and that allows all its rules to be defined in the ESLint config. Feels like they could stand to merge, like eslint+tslint.
- awestroke 3y agoMost projects use the same set of the most popular plugins. Shouldn't be a problem to get those plugins ported.