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

[andrewconnell]

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]

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]

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]

@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]

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]

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!

[msft-github-bot]

Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues