Support auto fixing of tslint issues and automatic formatting about fluidframework HOT 12 CLOSED

Auto-formatting would be nice. For the auto-fixing of tslint issues, do you mean an npm script to do so? - or to have it happen automatically on save? We chose to not have it happen automatically on save at the project level, because it comes to user preference when to apply the fixes. I set mine to auto-fix tslint issues on a separate keyboard shortcut for example.

If you want to auto-fix tslint on save, it can be set in your user settings. User settings apply to all projects you work with, unless explicitly overridden by a project setting. Below is the snippet to add:

"editor.codeActionsOnSave": {
    "source.fixAll": true
}

from fluidframework.

Happening on save would be ideal, I would prefer to avoid having to set a user preference on all my machines. I like that things "just work" for other repos as soon as I clone and npm install.

What scenario do you not want it to happen automatically on save? We have it enabled in a lot of the big Microsoft repos for Office Online and Outlook Web, not sure the use case where you want to manually waste your time sorting imports or adding blank lines at the end of files.

from fluidframework.

When saving frequently, it will prematurely run the fix all before the code is in a stable state. It might add invalid semicolons or weird indention throughout the file, mark properties as readonly that are planned to be modified, etc. By setting it to a keyboard shortcut, it means it doesn't need to be manually fixed, but can be fixed at a different frequency than saving. For example, Tony had set his to Ctrl+S, Ctrl+S so it's like saying "I'm really done with this, please clean it up".

from fluidframework.

That's interesting, I havent heard that complaint in other repos. At least having it run on git commit would be a good middle ground. A dev shouldn't have to do something special for this repo, in my opinion. Want to reduce the barrier to contributing as much as possible

from fluidframework.

Another painpoint I had this week when working in the fluid repo, this is very standard practice in OSS. Please reconsider this @curtisman. This + prettier would make it much easier for folks who work in multiple repos, each with their own conventions. At the very least make it a precommit hook, I wasted cycles having to do this manually since every other repo I work in does this automatically (office-bohemia, office-online-ui, flient-ui)

from fluidframework.

There might be middle ground here. With the concern about "autofixed" on save, I don't think that would be a solution. Having it as git commit hook might also take too long to run every time? How about if the local dev build have the eslint auto fix on? (And fail on CI build?)

from fluidframework.

I'd rather us go with what other repos are doing, since I haven't heard folks in other repos complain about the auto save behavior before. But I'm willing to settle for a middle ground solution here since the current experience is so poor.

The precommit hook should only run on the changed files, so I wouldn't expect a perf issue unless linting is slow for some reason in this repo.

from fluidframework.

I'll look into the build solution.

BTW, the current solution is npm run lint:fix if you found error.

Also, you should try out npm run build;fast instead the normal npm run build. That will not block the dependent package to build, so if you only have eslint error, all the package will still get built.

from fluidframework.

Thanks for the tips, I've been using those (would be great to have all these tips documented). It's just really frustrating to have to run that manually, especially since the conventions of this repo are different from the ones I normally work in (that could change with the move to prettier)

from fluidframework.

Please use #313 to discuss prettier in particular. Past opinions have been that it is too opinionated for this repo.

from fluidframework.

Closed by accident.

from fluidframework.

@tylerbutler could you get some folks to bring up the discussion around prettier on the issue. No one has commented on it since I opened it. Given that it's used in big repos like React and Fluent UI, I fear this more of a case where we're the ones the that are too opinionated :) But yeah, let's keep the rest of the prettier conversation there

from fluidframework.