amrbashir
commented
3 weeks ago Thanks for the detailed proposal.
I don't quite agree that we should make a centralized @tauri-apps/config-prettier config, I prefer each project has its own prettier config, as each project can have different maintainers with different preferences on how they would want to maintain their project. This ofc adds a bit of inconsistency across different repos but it shouldn't matter that much since the formatting is automatic and taken care of by pnpm format script.
Today, different versions of Prettier may be imported inside a single repository, in each subproject/package.json (example: 3.3.2, ^3.3.2 and 3.3.3
This is ofc not the intended behavior, in #10607, I migrated tauri repo to use pnpm and pnpm's workspaces feature and have moved the format and format:check scripts to the root package.json but I forgot to remove the dependency.
Introduction of the issue
Hello. I enjoy your project. I studied your repositories to identify the pain points.
I have proposed the pull request #10707 to start contributing.
The complexity of a project should not increase as it grows in size. My focus is to help you to make your code easier to maintain and to require less time to update, while keeping the code as flexible as before.
I understand that some design patterns that enforce centralized structures in the code help to avoid repetition of code. This is missing in parts of your code and it can generate bugs difficult to track.
Reasons
To start with little tasks, I propose a review of Prettier configs across all your active repositories.
In #10707 I propose to change the file format of Prettier, from its .json to .js format. This may be irrelevant for now, but this change opens the door to do something interesting in the future: the possibility of importing a centralized "Tauri prettier config". This object contains the expected common properties. Each repository applies this config and can continue to set local deviations on their local Prettier configs. The end result is: nothing is going to change in any repository regarding the linting results provided by Prettier. Instead of this, what is going to improve is the developer experience. The Prettier code is going to become more predictable and easier to maintain across your repositories.
Think about future major Prettier versions. If their team ever deprecate rules, when this happens, it is going to require substantial effort to implement, because each Prettier config in every repository will need to be reviewed. Each Prettier config is currently written differently in each config. There is no clear, documented reason regarding the need of the rules. I believe there is no reason to waste hours just to update dependencies each time when these contain breaking changes. You would need only to edit the Prettier config in a single file, release it as a package, and then update the version of this @tauri-apps/config-prettier package in every project. If any project needs to disable a rule, this is solved locally, and that's it.
The possibility of importing a centralized Prettier config as object follows the same pattern observed on ESLint.
The file format would need to change from Json to JavaScript. The Prettier config could be named as
.prettierrc.jsorprettier.config.jsinstead of.prettierrc. I went with the second one in #10707 for clarity, easier to understand.The current approach
Today, different versions of Prettier may be imported inside a single repository, in each subproject/package.json (example: 3.3.2, ^3.3.2 and 3.3.3);
This may generate conflicting scenarios because the different Prettier configs are sometimes divergent, their rules are different, although the configs remain to be called by the same script to affect the same files.
Scripts are also not predictable. Sometimes scripts are written with the same name, but their arguments are different, although the result is the same.
You can imagine that the combination of these 3 points (different Prettier versions, different configs and different scripts) may create subtle bugs or inconsistencies here or there. As a result, the code becomes more and more difficult to maintain as it increases in size.
These inconsistencies may be trivial in the case of Prettier, due to being an external tool, but these are inconsistencies that can be avoided.
I do not like when developers spend their time to solve bugs produced by inconsistencies in tools, or when they spend time propagating a change in every single project. This is prone to produce errors and it requires a considerable amount of time. I enjoy to make proposals like the current one to free our times to write actual code.
The current #10707 pull request is a first step. It removes different Prettier versions in a single repository (Prettier was not explicitly being required in 2 of the 3 package.jsons); the pull request also simplifies the Scripts according to recent Prettier developments (default arguments can be omitted); the pull request adds the argument "cache" to improve speed of linting process; at last, the pull request changes the format of Prettier config from .json to .js to open the door for a centralized Prettier config to come in the future.
I hope you enjoy this! I only can see benefits for your project.
Maybe this change can break one external tool or another in a first moment, but nothing that requires so much effort, when compared to the amount of effort needed today to modernize/update Prettier every single time.
Proposed steps
What is the process for publishing a new npm package that you prefer? If you agree with this proposal, could you please create a "@tauri-apps/config-prettier" repository OR a folder somewhere, for me to stark work upon your centralized Prettier config and prepare pull requests? I have already mapped what Prettier options you have in common in your repositories:
Prettier options in Tauri repositories
```json { "arrowParens": "avoid", // different in some configurations (avoid vs. always) "bracketSpacing": false, // different in some configurations (true vs. false) "disableLanguages": ['hbs', 'handlebars'], // present in one configuration "endOfLine": "lf", // present in one configuration "overrides": [ { "files": [".changes/**.md"], "options": { "singleQuote": false } }, { "files": "*.astro", "options": { "parser": "astro" } }, { "files": ["*.json", "*.md", "*.toml", "*.yml"], "options": { "useTabs": false } }, { "files": ["*.md", "*.mdx"], "options": { "printWidth": 80 } } ], "parser": "typescript", // different in some configurations (typescript, astro) "plugins": ["prettier-plugin-astro"], // present in one configuration "printWidth": 80, // different in some configurations, but 80 is used here "quoteProps": "as-needed", // present in one configuration "semi": false, // different in some configurations (true vs. false) "singleQuote": true, // consistent in most, except where it’s overridden for specific files "tabWidth": 2, // different in some configurations, but 2 is used here "trailingComma": "none", // different in some configurations (none, es5, all) "useTabs": false // consistent across all configurations } ```Expected result
After reviewing Prettier configs on your active repositories, I would enjoy myself to review: your ESLint configs in a similar way (inconsistencies too, deprecated methods, improvements when linting .json files); your .gitignores (propose a sense of organization with categories, instead of how currently it is organized, each line being written on demand; some negation expressions - that are detrimental to Git performance - can also be rewritte); some JavaScript packages may be replaced to similar ones that contain fewer and lighter dependencies, while being equivalent in terms of features. Pull requests that promote a holistical review.
All the best.