Can someone ELI5 what kind of linting is required for a transcribed code generated by TS compiler?
Rome: A Linter for JavaScript and TypeScript
91–100 of 140 posts
Re: Rome: A Linter for JavaScript and TypeScript
#92I feel so torn on this project. On the one hand, I want to root for sebmarkbage, who has done so much for the field. On the other, as someone who used to do some "JS platform" work at a tech company, I really don't want Rome to catch on. Yet Another Standard is really painful for the ecosystem, and while it's obnoxious that you need so many tools, at least we've finally settled (mostly) on good answers for each verti…
Honestly, I think your thinking is totally backwards.
Wanting a project to be successful because of the person who started it is a terrible reason and has had (unsurprisingly) terrible results wherever I've seen it in the OSS community.
I feel the exact opposite: things like Rome (and Deno) are exactly the kind of projects that are needed in order to sort out a horribly fractured eco-system. I don't care who built them as long as they work well to solve the problems that so clearly exist.
Re: Rome: A Linter for JavaScript and TypeScript
#93I feel so torn on this project. On the one hand, I want to root for sebmarkbage, who has done so much for the field. On the other, as someone who used to do some "JS platform" work at a tech company, I really don't want Rome to catch on. Yet Another Standard is really painful for the ecosystem, and while it's obnoxious that you need so many tools, at least we've finally settled (mostly) on good answers for each verti…
> standards for how things should be done I cannot deal with these kind of statements and that's probably why I never use linters for my own projects. And yes, my code is good enough, a linter won't make it any better. It just blocks me time and time again and litters the codebase with: // eslint-disable-next-line I never really understood why these tools are so popular and who really needs them. In the end it's all…
I think the benefits of linting are similar to writing tests.
Initially the practice is detestable, especially if you've already developed some hard-fought coding chops without them. But after some time the practice itself influences your ability to write better code to start with, and successive tests become terser and more useful.
I think the same is true for linting. I found being involved in projects that enforce linting rules on commit to be insufferable, so I installed Prettier and configured it to format on save. Over time the auto-formatter did less because of the habits I was picking up.
I did have to confront the idea of being less precious and attached to my own coding-style, but frankly I still have pretty strong opinions despite having an automaton do my thinking for me in some of the projects I work on.
Of course, neither tests nor linting are a panacea, but so long as you give a hoot to start with you won't be able to avoid writing better code after using them.
Re: Rome: A Linter for JavaScript and TypeScript
#94I feel so torn on this project. On the one hand, I want to root for sebmarkbage, who has done so much for the field. On the other, as someone who used to do some "JS platform" work at a tech company, I really don't want Rome to catch on. Yet Another Standard is really painful for the ecosystem, and while it's obnoxious that you need so many tools, at least we've finally settled (mostly) on good answers for each verti…
Honestly, I think your thinking is totally backwards. Wanting a project to be successful because of the person who started it is a terrible reason and has had (unsurprisingly) terrible results wherever I've seen it in the OSS community. I feel the exact opposite: things like Rome (and Deno) are exactly the kind of projects that are needed in order to sort out a horribly fractured eco-system. I don't care who built th…
> Wanting a project to be successful because of the person who started it is a terrible reason and has had (unsurprisingly) terrible results wherever I've seen it in the OSS community.
I somehow misinterpreted pipenv being an official python project. My usecase was pretty simple, I wanted a requirements.txt that only included the things I explicitly installed with perhaps a requirements-lock.txt with the actual list of things installed. :/
I didn’t even realize poetry existed until I talked to people who do python full time.
Re: Rome: A Linter for JavaScript and TypeScript
#95A few questions on top of my head when I consider changing the toolchain: - does it handle images imports - does it handle scss imports - if not, does it require css-in-js (and if so which one) - does it handle shaders imports (and other arbitrary dependencies that need custom processing to get embedded in the bundle) - does it generate SRI hashes for stylesheets and scripts - can it generate web workers - can it gen…
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.
It does matter if the only value of the linter at the moment is that it will be part of a set of tools to replace the entire toolchain.
It already took forever for the ecosystem to get JSHint, Tslint and others to converge into Eslint.
Re: Rome: A Linter for JavaScript and TypeScript
#96Earlier quoted context omitted.
> standards for how things should be done I cannot deal with these kind of statements and that's probably why I never use linters for my own projects. And yes, my code is good enough, a linter won't make it any better. It just blocks me time and time again and litters the codebase with: // eslint-disable-next-line I never really understood why these tools are so popular and who really needs them. In the end it's all…
I think the benefits of linting are similar to writing tests. Initially the practice is detestable, especially if you've already developed some hard-fought coding chops without them. But after some time the practice itself influences your ability to write better code to start with, and successive tests become terser and more useful. I think the same is true for linting. I found being involved in projects that enforce…
> Over time the auto-formatter did less because of the habits I was picking up.
Indeed, making you more robot for "how things should be done".
Just one example: I like my code to be readable, and one of the things I apply for that is the use of white space. Between my functions/methods I have at least 3 lines of white space. It's a lie that this is not "how things should be done", and there is no way to tell prettier to accept that because it is meant to be opinionated. These tools have a place for some teams and junior devs, but I try to stay away from the ugly code it spits out.
Re: Rome: A Linter for JavaScript and TypeScript
#97Earlier quoted context omitted.
Honestly, I think your thinking is totally backwards. Wanting a project to be successful because of the person who started it is a terrible reason and has had (unsurprisingly) terrible results wherever I've seen it in the OSS community. I feel the exact opposite: things like Rome (and Deno) are exactly the kind of projects that are needed in order to sort out a horribly fractured eco-system. I don't care who built th…
> Wanting a project to be successful because of the person who started it is a terrible reason and has had (unsurprisingly) terrible results wherever I've seen it in the OSS community. I somehow misinterpreted pipenv being an official python project. My usecase was pretty simple, I wanted a requirements.txt that only included the things I explicitly installed with perhaps a requirements-lock.txt with the actual list…
Yeah, that is an example that sprang to mind as soon as I read the GC.
Re: Rome: A Linter for JavaScript and TypeScript
#98Earlier quoted context omitted.
I think the benefits of linting are similar to writing tests. Initially the practice is detestable, especially if you've already developed some hard-fought coding chops without them. But after some time the practice itself influences your ability to write better code to start with, and successive tests become terser and more useful. I think the same is true for linting. I found being involved in projects that enforce…
> Over time the auto-formatter did less because of the habits I was picking up. Indeed, making you more robot for "how things should be done". Just one example: I like my code to be readable, and one of the things I apply for that is the use of white space. Between my functions/methods I have at least 3 lines of white space. It's a lie that this is not "how things should be done", and there is no way to tell prettier…
Good point on teams, but I'm not convinced that linting is a great tool for juniors in the same way. Frustration is an instrument for learning, but adhering to linting rules forces that energy in the wrong direction for those still going through the basics.
On the point of being a robot, in what way are we not already "robots" by stubbornly sticking to what we think of as best? Are you not already a robot by limiting yourself to a narrow-range of what you consider "readable"?
I also find it annoying to occasionally lose white-space to Prettier. But I've learned my way around it: By either adding short comments or by decomposing single-lines into multiple ones, which ends up improving readability anyway.
Re: Rome: A Linter for JavaScript and TypeScript
#99Earlier quoted context omitted.
Hey there – I do mix the two of you up, but Babel is nothing to scoff at. I've used its internals in the past, and read a good chunk of its source code, so I think I've seen your blames all over. I'm quite appreciative of your past contributions! (and his) Reading your comment, it sounds like you expect some people might use Rome for some things (say, linting and compilation) and preexisting tools for others (say, fo…
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…
Very interesting! Thanks for clarifying.
I've also done some work on Prettier in the past, so I'm curious about some details there too.
1. Do you plan to build a wadler-based formatter, similar to prettier? Will it be as opinionated as prettier, or based on a pluggable architecture? (I'll admit that I have yet to conceive of a viable way to make the latter work well).
2. Have you considered (or already built) an incremental parsing server for tools like the formatter? For example, when I add a statement at the bottom of the document, will it reparse the whole document, or be smart enough to notice that a change has been made that can use cached results for most of the AST? (I'm not sure if this is feasible for JS, especially for parsers that require line/col info).
In any case, I'll be following your progress with great interest!
Re: Rome: A Linter for JavaScript and TypeScript
#100There's something that scares me about Rome: it's lack of plugins. I really like Babel because of its plugins. My project typecheck.macro, could not exist without Babel plugins. How will Rome support compile time transformations like graphql.macro or typecheck.macro? Compile time plugins allow JavaScript to evolve super rapidly & make the creation of frameworks that act as compilers instead of traditional frameworks…
Isn't this the reason why it is called Rome? In JavaScript history, we are past Babel (and the Greek city states) and a centralized tooling will allow for an unprecedented language economy? Constantinople and Moscow are waiting, as well as Venice and London. A plugin system that wants to incorporate everything will risk having to maintain Byzantine diplomatic relations. On the other hand, restricting the plugin syste…
My guess is "all roads lead to Rome".