Editorial: Fix linter errors in spec #499
Conversation
package.json
Outdated
| @@ -5,15 +5,15 @@ | |||
| "description": "ECMAScript Internationalization API Specification", | |||
| "scripts": { | |||
| "build-es2020": "git remote remove origin && git remote add origin \"git@github.com:$TRAVIS_REPO_SLUG.git\" && git fetch --quiet origin && git checkout --quiet es2020 && mkdir \"out/2020\" && cp -R img \"out/2020\" && ecmarkup --verbose spec/index.html out/2020/index.html --css out/2020/ecmarkup.css --js out/2020/ecmarkup.js", | |||
| "build-master": "mkdir out && cp -R img out && ecmarkup --verbose spec/index.html out/index.html --css out/ecmarkup.css --js out/ecmarkup.js", | |||
| "build-master": "mkdir -p out && cp -R img out && ecmarkup --lint-spec --verbose spec/index.html out/index.html --css out/ecmarkup.css --js out/ecmarkup.js", | |||
There was a problem hiding this comment.
I had it in a separate commit, but yes it is necessary if you want to run npm run build-master twice in a row.
There was a problem hiding this comment.
I don't have strong feelings about this, but adding -p here will suppress the error that would otherwise abort progress when an "out" directory already exists. The ECMA 262 approach is probably better, but also too complex for my taste.
There was a problem hiding this comment.
It was just a fix for convenience, if it has other disadvantages then I'll go ahead and remove it.
| @@ -35,42 +35,42 @@ <h1>Intl[ @@toStringTag ]</h1> | |||
| <h1>Constructor Properties of the Intl Object</h1> | |||
|
|
|||
| <emu-clause id="sec-intl.locale-intro"> | |||
| <h1>Intl.Locale (...)</h1> | |||
| <h1>Intl.Locale ( . . . )</h1> | |||
There was a problem hiding this comment.
It in necessary to put the space between the dots too?
There was a problem hiding this comment.
According to the ecmarkup linter, yes.
There was a problem hiding this comment.
It brings this spec into alignment with ECMA 262 (example), so I'm in favor.
| @@ -251,6 +250,7 @@ <h1>get Intl.Locale.prototype.baseName</h1> | |||
| 1. Perform ? RequireInternalSlot(_loc_, [[InitializedLocale]]). | |||
| 1. Let _locale_ be _loc_.[[Locale]]. | |||
| 1. Return the substring of _locale_ corresponding to the `unicode_language_id` production. | |||
| </emu-alg> | |||
| @@ -35,42 +35,42 @@ <h1>Intl[ @@toStringTag ]</h1> | |||
| <h1>Constructor Properties of the Intl Object</h1> | |||
|
|
|||
| <emu-clause id="sec-intl.locale-intro"> | |||
| <h1>Intl.Locale (...)</h1> | |||
| <h1>Intl.Locale ( . . . )</h1> | |||
There was a problem hiding this comment.
It brings this spec into alignment with ECMA 262 (example), so I'm in favor.
package.json
Outdated
| @@ -5,15 +5,15 @@ | |||
| "description": "ECMAScript Internationalization API Specification", | |||
| "scripts": { | |||
| "build-es2020": "git remote remove origin && git remote add origin \"git@github.com:$TRAVIS_REPO_SLUG.git\" && git fetch --quiet origin && git checkout --quiet es2020 && mkdir \"out/2020\" && cp -R img \"out/2020\" && ecmarkup --verbose spec/index.html out/2020/index.html --css out/2020/ecmarkup.css --js out/2020/ecmarkup.js", | |||
| "build-master": "mkdir out && cp -R img out && ecmarkup --verbose spec/index.html out/index.html --css out/ecmarkup.css --js out/ecmarkup.js", | |||
| "build-master": "mkdir -p out && cp -R img out && ecmarkup --lint-spec --verbose spec/index.html out/index.html --css out/ecmarkup.css --js out/ecmarkup.js", | |||
There was a problem hiding this comment.
I don't have strong feelings about this, but adding -p here will suppress the error that would otherwise abort progress when an "out" directory already exists. The ECMA 262 approach is probably better, but also too complex for my taste.
Based on a discussion in Temporal [1], it seems like it might be a good idea to run ecmarkup's linter on the spec, now that in version 4.1.0 has brought several bug fixes in the linter. This adds the linter to the build process, but without making it fail the build if any warnings are detected, since some of the "errors" are intentional. (The intentional ones are marked with a comment.) [1] tc39/proposal-temporal#870
Based on a discussion in Temporal, it seems like it might be a good idea to run ecmarkup's linter on the spec, now that in version 4.1.0 has brought several bug fixes in the linter.
This adds the linter to the build process and makes it fail if any warnings are generated.