-
Notifications
You must be signed in to change notification settings - Fork 656
Conversation
✅ Deploy Preview for docs-rometools ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site settings. |
{ | ||
"scripts": { | ||
- "lint": "next lint" | ||
+ "lint": "rome check ." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we've shipped it in time, we should recommend --force-colors
here. Otherwise the output looks shite calling through turbo lint in the root
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That will be part of the next release :) #3625
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup I saw, just not sure if that'll be out soon enough before this is merged
```diff | ||
"scripts": { | ||
- "lint": "eslint --fix ." | ||
+ "lint": "rome check --apply .", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This lint command is unfortunately not equivalent right now. If rome finds an error that has a suggested fix, it will print "skipped 1 suggested fix" and not highlight the problem and exit with 0. This seems unintuitive to me, does anyone know if this is intended or discussed in some issue?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's intentional. rome check
is supposed to be the command to make sure the code is correct. --apply
and --apply-suggested
are volountary commands where the user decides to fix the code and how to fix it. It seems a bit redundant to show them diagnostics (at least the ones related to linting).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay. That still seems unintuitive to me to be honest, as flags usually only alter/augment the behavior of a command and this seems to be more like a completely different command (rome apply
).
I think in this guide I can still leave it as a recommendation despite the different behavior, since I'm not recommending anyone to use this command for CI or anything dangerous like that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It makes sense, thank you for the suggestion.
FYI we plan to remove --apply-suggested
in the next months. This command was created as a quick workaround to allow users to apply also suggested fixes, but the correct way to do so would be to use a rome check --review
argument that enables an interactive review where users can decide to:
- apply the suggested fix
- or suppress the rule
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Co-authored-by: Superchupu <53496941+SuperchupuDev@users.noreply.github.com>
```json | ||
{ | ||
"formatter": { | ||
"ignore": ["build", "**/*.generated.js"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This and similar code examples should likewise also be adapted when we ship files.ignore
, again not sure if release will be before this doc merge
} | ||
``` | ||
|
||
Do not quote a pattern like `**/*.ts`. Most modern package managers are able to handle it correctly on all platforms. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IIRC there's an issue to implement glob patterns in Rome. I think it would be useful to do that to reduce reliance on package managers here. Recommending to run through package manager scripts is generally a bit of an eyesore to me, because it's so much slower. It would be nice to have a better way that we can confidently recommend to people. In the meantime, any further dependency on package managers such as for globbing would be good to avoid for future-proofing
Alright, happy with this first version. If we notice a significant amount of people struggling with a particular part, we can make optimizations / further expand there. |
- "format": "prettier --write ." | ||
+ "format": "rome format --write .", | ||
- "ci:format": "prettier --check ." | ||
+ "ci:format": "rome format .", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this is the correct transition, rome format
doesn't return an error code here, while prettier does. The correct way for us to suggest the transition for CI environments should be:
rome ci --linter-enabled=false .
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ohh that's true, I never looked at the exit code, only assumed it would exit 1 if it prints the formatter diff. I will change this for the guide.
Are you aware of discussion threads or so on the CLI design? There have been a few design decisions now that struck me as odd compared to existing JS tools and also other CLI tools, would be good to get more context or to get involved if there are still active discussions about potential changes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There have been some issue around the unclearness/oddity of how error codes are returned from our commands.
There have been talks between the staff team about using error codes in a better way (a la' prettier), and we do want to use this Rust primitive, but we haven't had the time to look into it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Feel free to start a github discussion if you have suggestions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I commented on #3443 to keep it in one place. I think there's a good way forward.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Path forward for this and the other instances of it that I have in mind: We recommend an example like
"format": "rome format --write .",
"check:format": "rome format --check .",
"lint": "rome check --fix .",
"check:lint": "rome check ."
but add a CI section like at the start of the guide to clarify that CI should run not these but rome ci
(if necessary with parts of Rome disabled via rome.json
)
@sebmck @MichaReiser feel free to also leave a review on whether this is coherent and the suggestions made to users are good 😅 |
Probably best to wait with merging this until we have resolved the awkwardness of not having good replacements for |
* upstream/main: (73 commits) fix(semantic_analyzers): style/noShoutyConstants does not recognize multiple uses of a constant. (rome#3789) feat(rome_js_analyze): useDefaultSwitchClauseLast (rome#3791) chore: run rustfmt and typo fix (rome#3840) feat(rome_js_analyze): use exhaustive deps support properties (rome#3581) website(docs): Fix text formatting (rome#3828) feat(rome_js_analyze): `noVoidTypeReturn` (rome#3806) feat(rome_cli): expose the `--verbose` flag to the CLI (rome#3812) fix(rome_diagnostics): allow diagnostic locations to be created without a resource (rome#3834) feat(rome_js_analyze): add noExtraNonNullAssertion rule (rome#3797) fix(rome_lsp): lsp friendly catch unwind (rome#3740) feat(rome_js_semantic): model improvements (rome#3825) feat(rome_json_parser): JSON Lexer (rome#3809) feat(rome_js_analyze): implement `noDistractingElements` (rome#3820) fix(rome_js_formatter): shothanded named import line break with default import (rome#3826) feat(rome_js_analyze): `noConstructorReturn` (rome#3805) feat(website): change enabledNurseryRules to All/Recommended select (rome#3810) feat(rome_js_analyze): noSetterReturn feat(rome_js_analyze): noConstructorReturn feat(rome_analyze): suppress rule via code actions (rome#3572) feat(rome_js_analyze): `noVar` (rome#3765) ...
|
||
### CI | ||
|
||
If you have a CI pipeline, such as GitHub Actions, we recommend that you check formatting and linting as part of it by adding the following command: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be practical to include a guide on (or at the very least, a reference to) the Rome GitHub action & how it can be setup in a GitHub repository.
Resolves #3708
Took a little more time today to almost finish this, just gotta write a little bit about package manager workspaces/lerna.
I'm trying to make the guide very approachable with little knowledge about any tooling configuration whatsoever. I give copy paste replacements that work if you have done the basic setup recommended by Prettier/ESLint/Turborepo/... and would like to replace a tool with Rome. Of course this cannot cover complex setups and configuration in detail, but if users have done that, they probably have some experience with tooling and can figure out those remaining modifications afterwards.
At the same time, I try to nudge users to do things in a future-proof way. E.g.
ignore
instead of include patterns so that users will automatically benefit when we become capable of formatting additional file types. And using Rome directly in the root if possible because we'll have features for multi-package repos in the future.