-
Notifications
You must be signed in to change notification settings - Fork 27.4k
chore(docs): improve version picker #15385
chore(docs): improve version picker #15385
Conversation
@@ -39,7 +39,8 @@ module.exports = function productionDeployment(getVersion) { | |||
'components/lunr.js-' + getVersion('lunr.js') + '/lunr.min.js', | |||
'components/google-code-prettify-' + getVersion('google-code-prettify') + '/src/prettify.js', | |||
'components/google-code-prettify-' + getVersion('google-code-prettify') + '/src/lang-css.js', | |||
'js/versions-data.js', | |||
'js/version-data.js', | |||
'https://code.angularjs.org/snapshot/docs/js/versions-data.js', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
note that in production we read the list from snapshot
otherwise we just use the local
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will require some CORS setup on code.angularjs.org I think
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
actually no it won't because we are loading via a script not XHR
fe01070
to
4c41ec7
Compare
We could change the docs apps for most releases on code.angularjs.org to use this same code. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few minor things that shold be clarified, otherwise I really like the solution.
@@ -346,7 +346,7 @@ module.exports = function(grunt) { | |||
|
|||
grunt.registerTask('minify', ['bower', 'clean', 'build', 'minall']); | |||
grunt.registerTask('webserver', ['connect:devserver']); | |||
grunt.registerTask('package', ['bower', 'validate-angular-files', 'clean', 'buildall', 'minall', 'collect-errors', 'docs', 'copy', 'write', 'compress']); | |||
grunt.registerTask('package', ['bower', 'validate-angular-files', 'clean', 'buildall', 'minall', 'collect-errors', 'write', 'docs', 'copy', 'compress']); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why this change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is because the version.json file is generated by the write
grunt task. So we need it to run before the docs
task, which now relies upon it.
var output = exec('npm info angular versions --json', { silent: true }).stdout; | ||
var versions = processAllVersionsResponse(JSON.parse(output)); | ||
|
||
docs.push({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we call this current-version-data? This makes it clearer what's the difference from version-data.js
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I agree that the visual difference between versions and version is not that obvious
$process: function(docs) { | ||
|
||
var versionDoc = { | ||
var blacklist = this.blacklist; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the meaning of the blacklist? Can you please add a comment?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK. The main reason was that we appear to have npm published a random rogue release, 1.3.4-build.3588, which does not have an associated folder on code.angularjs.org
} | ||
return version; | ||
}) | ||
.filter(function(version) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAICT, filtering after having populated latestMap
, will allow 0.x
versions to appear in the "Latest" group of the dropdown. The filtering should be done before populating ``latestMap`.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't reproduce this locally. It also looks like we don't include any 0.x versions at all.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't try it locally, but from looking at the code I assumed that 0.x versions would be shown in the "Latest" group. Are you sure they are not there (only in the "Latest" group though).
Not directly related to this PR, but close enough: |
The build number is shown on the api docs home page. Why do you want to have it in the picker? |
Convenience :) It makes it easy to see when refreshing the page gets you a newer build. |
I think we should display the build number of the docs somewhere on the page. Perhaps near the bottom? |
4c41ec7
to
0f2f08b
Compare
0f2f08b
to
ce49edc
Compare
The build number is displayed in the footer. :D On docs/api (main page), then it's also in the first paragraph. |
Right. But you have to scroll all the way down to see the footer 😃 |
LGTM as long as Travis is happy. |
Travis is not happy but it is an east fix |
Travis is now happy - after a copied the all-versions.js file onto the snapshot :-) |
See 4836278 |
What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
chore
What is the current behavior? (You can also link to an open issue here)
Versions in the version picker are hard-coded into each build
This means that newer versions are never shown in older versions of the docs
What is the new behavior (if this is a feature change)?
Now the version information has split into the current and the list of all versions.
In the production deployment the version list is now read from the snapshot build, so we always
get the latest list.
Does this PR introduce a breaking change?
No
Please check if the PR fulfills these requirements
Other information:
Replaces #15381