Setup format, husky & lint-staged

[abdonrd]

Continuing the work from #398 (from lit/lit#1351)...

• Setup format scripts with Prettier & ESLint.
• Remove clang-format references.
• Setup husky & lint-staged.

I save the auto-format to just one commit to easy review: e509977

With this PR, the mono-repository has exactly the same configuration as the lit-html mono-repository.

[abdonrd]

@bicknellr done!

• master is merged
• Setup ignore sync (is what we use in lit-html mono-repo). 781c3d5
• Add format step to CI. 421e131

[googlebot]

A Googler has manually verified that the CLAs look good.

(Googler, please make sure the reason for overriding the CLA status is clearly documented in these comments.)

ℹ️ Googlers: Go here for more info.

[google-cla]

A Googler has manually verified that the CLAs look good.

(Googler, please make sure the reason for overriding the CLA status is clearly documented in these comments.)

ℹ️ Googlers: Go here for more info.

[googlebot]

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and then comment @googlebot I fixed it.. If the bot doesn't comment, it means it doesn't think anything has changed.

ℹ️ Googlers: Go here for more info.

[bicknellr]

Neat! I didn't know about ignore-sync before - seems like just what we needed here. Also, I pushed a few extra commits in a local branch (format) (diff), PTAL. If those seem ok to you, then I think this is ready to go.

[abdonrd]

Thanks @bicknellr! Now I've caught those commits!

Except this (abdonrd@3dfa021); I don't know why, but the tests breaks if we remove it.

[abdonrd]

@bicknellr Maybe I did something wrong, because everything is already working! 🎉

[bicknellr]

I ran into that same problem yesterday when I pulled up the tests locally. This snippet was running before eventPropertyNamesForElement was defined:

polyfills/packages/shadydom/src/patches/Element.js

Lines 127 to 129 in bed5d99

	eventPropertyNamesForElement.forEach(property => {
	ElementPatches[property] = wrappedDescriptorForEventProperty(property);
	});

Normally this would mean that eventPropertyNamesForElement is part of an import cycle, but it comes from patch-events.js and that module and the ones below it have no cycles. (There's at least one cycle that patches/Element.js itself is part of, but that shouldn't affect eventPropertyNamesForElement.) Then I stumbled on this in the build output:

@webcomponents/shadydom: gulp-google-closure-compiler: src/patches/Element.js:128: WARNING - [JSC_NAME_DEFINED_LATE] eventPropertyNamesForElement$$module$src$patch_events.forEach defined before its owner. eventPropertyNamesForElement$$mod
ule$src$patch_events is defined at src/patch-events.js:757                                                                                                                                                                                    
@webcomponents/shadydom:   eventPropertyNamesForElement.forEach((property) => {                                                                                                                                                               
@webcomponents/shadydom:   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^                                                                                                                                                                               
@webcomponents/shadydom: src/patches/HTMLElement.js:33: WARNING - [JSC_NAME_DEFINED_LATE] eventPropertyNamesForHTMLElement$$module$src$patch_events.forEach defined before its owner. eventPropertyNamesForHTMLElement$$module$src$patch_event
s is defined at src/patch-events.js:761                                                                                                                                                                                                       
@webcomponents/shadydom:   eventPropertyNamesForHTMLElement.forEach((property) => {                                                                                                                                                           
@webcomponents/shadydom:   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^                                                                                                                                                                           
@webcomponents/shadydom: 0 error(s), 2 warning(s), 77.1% typed                                                                                                                                                                                

Closure has a dependency_mode flag that defaults to NONE, which apparently just includes all of the files in the order they're listed. So, my assumption is that we'd just been lucky regarding the import ordering until now and that changing that line somehow affected the order that the files were given to Closure, which sometimes broke the output.

Was your build ever broken when both entry_point was specified and those import lines weren't being ignored by prettier? I wonder if we should explicitly set dependency_mode to PRUNE; maybe entry_point doesn't necessarily imply ordering.

[abdonrd]

I have issues with the tests locally (Java related):

[bicknellr]

Oh, was that what was happening for you before when you mentioned the tests weren't working? Or were they previously running but with failures?

[abdonrd]

Oh, was that what was happening for you before when you mentioned the tests weren't working? Or were they previously running but with failures?

Yes, I already had this problem before. It's an issue with wct and Java in my laptop.

[googlebot]

A Googler has manually verified that the CLAs look good.

(Googler, please make sure the reason for overriding the CLA status is clearly documented in these comments.)

ℹ️ Googlers: Go here for more info.

[google-cla]

A Googler has manually verified that the CLAs look good.

(Googler, please make sure the reason for overriding the CLA status is clearly documented in these comments.)

ℹ️ Googlers: Go here for more info.

[bicknellr]

Ok, in that case I'm going to go ahead and merge. Maybe I'll post another PR later to handle the dependency_mode thing, but I don't think it strictly needs to be addressed here. Thanks for this PR and your patience!

[abdonrd]

Thanks you too @bicknellr! Happy to finally merge it!