New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

❓Why are editorconfig, npmignore, and gitattributes/gitignore included by default #653

Closed
andrewconnell opened this Issue Jun 19, 2017 · 5 comments

Comments

Projects
None yet
2 participants
@andrewconnell
Collaborator

andrewconnell commented Jun 19, 2017

Category

  • Question
  • Typo
  • Bug
  • Additional article idea

Granted, they have no adverse affect on the project...

except to pollute it with extra junk we don't need

Why are these files included by default on new project creation?

My $0.02:

  • .editorconfig: just a preference... Microsoft forcing specific style over others that developers may prefer
  • .npmignore: according to NPM's own docs, this is only used to ignore things going into a package... but no one will ever do this with a SPFx project... you'll never deploy SPFx projects => npmjs.org... so why include it?
  • .gitattributes: including this is simply unnecessary... if developers have people on Windows & MacOS machines, they may want it... but from a global setup, not on a project by project basis
  • .gitignore: ok... I grant why you might want this... BUT... the project isn't creating a git repo so why default to include it?

IMHO, .editorconfig & .npmignore should not be included in new projects in any situation. There are plenty of options for developers to add them themselves at a later date using other generators.

IMHO, .gitattributes should not be included... if MSFT feels strongly it should be included, give us an opt-in (or since the house is already out of the stable, opt-out) argument.

@chakkaradeep

This comment has been minimized.

Show comment
Hide comment
@chakkaradeep

chakkaradeep Jul 6, 2017

Collaborator

Thanks for reporting this.

Agree on the .gitattributes and .npmignore. We will be removing those as they do not apply to the solution.

However, we believe the .editorconfig and .gitignore provide value to the developers.

  • .gitignore: This is going to be very useful if the developer is using git as the source control system. Even if they do not choose git, they can quickly scan the patterns or in some cases just copy/paste the patterns in their respective source control ignore file.

  • .editorconfig: As many SharePoint developers are new to client-side solutions, this file is going to help them kick start the development with a default coding style preferred by SharePoint team. The ones we have in the .editorconfig also match the coding styles for the files we ship (sample code and node_modules@microsoft) and hence help developers when they specifically view those files. If developers want to overwrite with their own config, they can do so as you suggested using different tools available.

Collaborator

chakkaradeep commented Jul 6, 2017

Thanks for reporting this.

Agree on the .gitattributes and .npmignore. We will be removing those as they do not apply to the solution.

However, we believe the .editorconfig and .gitignore provide value to the developers.

  • .gitignore: This is going to be very useful if the developer is using git as the source control system. Even if they do not choose git, they can quickly scan the patterns or in some cases just copy/paste the patterns in their respective source control ignore file.

  • .editorconfig: As many SharePoint developers are new to client-side solutions, this file is going to help them kick start the development with a default coding style preferred by SharePoint team. The ones we have in the .editorconfig also match the coding styles for the files we ship (sample code and node_modules@microsoft) and hence help developers when they specifically view those files. If developers want to overwrite with their own config, they can do so as you suggested using different tools available.

@andrewconnell andrewconnell changed the title from Why are editorconfig, npmignore, and gitattributes/gitignore included by default to ❓Why are editorconfig, npmignore, and gitattributes/gitignore included by default Jul 7, 2017

@andrewconnell

This comment has been minimized.

Show comment
Hide comment
@andrewconnell

andrewconnell Jul 7, 2017

Collaborator

Thanks @chakkaradeep on removing the two unnecessary files.

Respectfully disagree with you on .editorconfig as well as the inclusion of tslint.json.

IMHO, templates from vendors should provide the necessary functionality, but not impose style. Any of your enterprise customers are likely to have their own coding standards. I guess the solution is to remove what the MSFT generator does and replace it with our own on every project. Tedious, but doable.

Leaving this open until the .gitattributes & .npmignore are removed.

Collaborator

andrewconnell commented Jul 7, 2017

Thanks @chakkaradeep on removing the two unnecessary files.

Respectfully disagree with you on .editorconfig as well as the inclusion of tslint.json.

IMHO, templates from vendors should provide the necessary functionality, but not impose style. Any of your enterprise customers are likely to have their own coding standards. I guess the solution is to remove what the MSFT generator does and replace it with our own on every project. Tedious, but doable.

Leaving this open until the .gitattributes & .npmignore are removed.

@chakkaradeep

This comment has been minimized.

Show comment
Hide comment
@chakkaradeep

chakkaradeep Jul 7, 2017

Collaborator

@andrewconnell I don't believe we are imposing anything. What contradicting styles or configurations do you think we are imposing that is going to degrade the development standards of an enterprise? Would like to know if that is the case, then maybe we could update those files to have the right configurations.

Also, the template does not stop the developer from overwriting the configurations. So, I am unclear as to how that results in imposing styles. If you as a developer have in your workflow to put your own configuration, you would do so anyways.

Collaborator

chakkaradeep commented Jul 7, 2017

@andrewconnell I don't believe we are imposing anything. What contradicting styles or configurations do you think we are imposing that is going to degrade the development standards of an enterprise? Would like to know if that is the case, then maybe we could update those files to have the right configurations.

Also, the template does not stop the developer from overwriting the configurations. So, I am unclear as to how that results in imposing styles. If you as a developer have in your workflow to put your own configuration, you would do so anyways.

@andrewconnell

This comment has been minimized.

Show comment
Hide comment
@andrewconnell

andrewconnell Jul 7, 2017

Collaborator

You're correct... the developer can make changes after creating the project... no debate there. And just to state the obvious: this isn't a bug / complaint... just a debate.

I don't believe we are imposing anything

The very presence of these two files (.editorconfig & tslint.json) imposes styles... maybe not the former, but the latter (tslint) absolutely does.

Consider an analogy: when I create a new ASP.NET MVC project in Visual Studio, do you see any FxCop or StyleCop rules provisioned with the project? When I the ASP.NET Core Yeoman generator, you don't see any style-like files, including .editorconfig.

So I ask: what makes SPFx so special from other MSFT templates that it should include that stuff?

Collaborator

andrewconnell commented Jul 7, 2017

You're correct... the developer can make changes after creating the project... no debate there. And just to state the obvious: this isn't a bug / complaint... just a debate.

I don't believe we are imposing anything

The very presence of these two files (.editorconfig & tslint.json) imposes styles... maybe not the former, but the latter (tslint) absolutely does.

Consider an analogy: when I create a new ASP.NET MVC project in Visual Studio, do you see any FxCop or StyleCop rules provisioned with the project? When I the ASP.NET Core Yeoman generator, you don't see any style-like files, including .editorconfig.

So I ask: what makes SPFx so special from other MSFT templates that it should include that stuff?

@chakkaradeep

This comment has been minimized.

Show comment
Hide comment
@chakkaradeep

chakkaradeep Jul 7, 2017

Collaborator

We believe these add additional value to the development flow. We have received positive feedback on the tslint.json and have provided ways to turn it off, if needed, based on the feedback. Moreover, the tslint configurations work with the SPFx build pipeline and toolchain giving the much-needed help for developers to avoid any accidental/unwanted errors when building web parts and other SPFx components.

We are not saying SPFx is special rather providing options/ways to help developers write better code. The developer, at the end of the day, can decide not to use any of these and remove/ignore them if they want to.

We don't have any intention to remove these files other than the .gitattributes and .npmignore from the template. I am closing this issue as this is by design.

Thanks!

Collaborator

chakkaradeep commented Jul 7, 2017

We believe these add additional value to the development flow. We have received positive feedback on the tslint.json and have provided ways to turn it off, if needed, based on the feedback. Moreover, the tslint configurations work with the SPFx build pipeline and toolchain giving the much-needed help for developers to avoid any accidental/unwanted errors when building web parts and other SPFx components.

We are not saying SPFx is special rather providing options/ways to help developers write better code. The developer, at the end of the day, can decide not to use any of these and remove/ignore them if they want to.

We don't have any intention to remove these files other than the .gitattributes and .npmignore from the template. I am closing this issue as this is by design.

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment