Implement Site.Prototype methods in ES6 syntax #2280

[jmestxr]

What is the purpose of this pull request?

• Documentation update
• Bug fix
• Feature addition or enhancement
• Code maintenance
• DevOps
• Improve developer experience
• Others, please explain:

Resolves #2280 according to solution proposed in #979

Overview of changes:

• Refactor Site.prototype methods implemented in Site/index.ts using ES6 class syntax

Anything you'd like to highlight/discuss:

Testing instructions:

npm run test

Proposed commit message: (wrap lines at 72 characters)

Refactor Site.prototype methods in ES6 syntax

---

Checklist: ☑️

• Updated the documentation for feature additions and enhancements
• Added tests for bug fixes or features
• Linked all related issues
• No unrelated changes

[tlylt]

solution proposed in #979

Which solution are you referring to?

[jmestxr]

solution proposed in #979

Which solution are you referring to?

I was referring to this comment: #979 (comment)
using this syntax: rebuildAffectedSourceFiles = delay(this._rebuildAffectedSourceFiles, 1000);

ESlint doesn't show any parsing errors for me so I assumed it was updated alr.

[tlylt]

solution proposed in #979

Which solution are you referring to?

I was referring to this comment: #979 (comment) using this syntax: rebuildAffectedSourceFiles = delay(this._rebuildAffectedSourceFiles, 1000);

ESlint doesn't show any parsing errors for me so I assumed it was updated alr.

I see, so because class fields proposal is accepted in TC39 hence there is no more syntax error complained by Eslint?
Could you investigate the browser support for class fields since it's only accepted last year (2022)?

I briefly searched it and found that class fields seem to not work in IE at all and have about ~92% support globally
https://caniuse.com/?search=class%20field

It's not a big issue, but good to find out more before we make this change.

[jmestxr]

I see, so because class fields proposal is accepted in TC39 hence there is no more syntax error complained by Eslint? Could you investigate the browser support for class fields since it's only accepted last year (2022)?

I briefly searched it and found that class fields seem to not work in IE at all and have about ~92% support globally https://caniuse.com/?search=class%20field

It's not a big issue, but good to find out more before we make this change.

I did some search and the browser support for both constructor and class fields are similar, so logically speaking, MarkBind should be able to continue supporting the browsers that we are currently supporting.

Javascript class is not supported in IE at all: https://caniuse.com/?search=class. So anyway, our current MarkBind is not supported in IE at all

[codecov]

Codecov Report

Merging #2356 (b18857a) into master (34493cc) will increase coverage by 0.05%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #2356      +/-   ##
==========================================
+ Coverage   45.11%   45.16%   +0.05%     
==========================================
  Files         123      123              
  Lines        5165     5159       -6     
  Branches     1086     1086              
==========================================
  Hits         2330     2330              
+ Misses       2516     2510       -6     
  Partials      319      319              

Files Changed	Coverage Δ
packages/core/src/Site/index.ts	29.75% <100.00%> (+0.22%)	⬆️

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[tlylt]

LGTM

[tlylt]

hmm, maybe there's something wrong here. I'm not sure why we are rebuilding all source files when one file is added/removed. Anyhow, it's not related to this PR.

[tlylt]

Might cause a type problem in the future when serveUtil.js is migrated to TypeScript, but should be ok for now.