Fixed js-guide links for real this time [ci skip]

corehq/apps/analytics/README.md

@@ -11,7 +11,7 @@ This varies depending on the service; see details on individual services below.
 
 ### Client Side
 
-For passing data from the server to the client, which is mostly API keys, analytics uses a variation on [initial_page_data](https://github.com/dimagi/commcare-hq/blob/master/docs/js-guide/blob/master/integration-patterns.md): same general idea, but with better namespacing and accessed via [initial.js](https://github.com/dimagi/commcare-hq/blob/master/corehq/apps/analytics/static/analytix/js/initial.js). Most of the analytics templates just contain this initial data, while a few contain the actual third-party scripts (for the services that don't interact with any other HQ JavaScript).
+For passing data from the server to the client, which is mostly API keys, analytics uses a variation on [initial_page_data](https://github.com/dimagi/commcare-hq/blob/master/docs/js-guide/integration-patterns.md): same general idea, but with better namespacing and accessed via [initial.js](https://github.com/dimagi/commcare-hq/blob/master/corehq/apps/analytics/static/analytix/js/initial.js). Most of the analytics templates just contain this initial data, while a few contain the actual third-party scripts (for the services that don't interact with any other HQ JavaScript).
 
 Analytics has its own logging infrastructure, is set up in [logging.js](https://github.com/dimagi/commcare-hq/blob/master/corehq/apps/analytics/static/analytix/js/logging.js) and prints to the browser console. The logging level can be controlled via `settings.ANALYTICS_CONFIG['LOG_LEVEL']` (see "Debugging" below).
 

docs/js-guide/code-organization.md

@@ -72,7 +72,7 @@ We're in the process of migrating to [RequireJS](https://requirejs.org/). Part o
 
 `hqDefine` serves as a stepping stone between legacy code and requirejs modules: it adds encapsulation but not
 full-blown dependency management. **New code should be written to be compatible with RequireJS.** This is typically
-easy; once familiar with the module patterns described below, see the [migration guide](https://github.com/dimagi/commcare-hq/blob/master/docs/js-guide/blob/master/migrating.md#migrating-to-requirejs) for details on making sure your code will work with RequireJS.
+easy; once familiar with the module patterns described below, see the [migration guide](https://github.com/dimagi/commcare-hq/blob/master/docs/js-guide/migrating.md#migrating-to-requirejs) for details on making sure your code will work with RequireJS.
 
 Before diving into `hqDefine`, I want to talk first about the status quo
 convention for sanity with no module system.

docs/js-guide/integration-patterns.md

@@ -130,7 +130,7 @@ $.get(initial_page_data.reverse('more_widget_info', widgetId)).done(function ()
 
 `registerurl` is essentially a special case of initial page data, and it gets messy when used in partials in the
 same way as initial page data. Encoding a url in a DOM element, in an attribute like `data-url`, is sometimes
-cleaner than using the `registerurl` template tag. See [partials](https://github.com/dimagi/commcare-hq/blob/master/docs/js-guide/blob/master/integration-patterns.md#partials) above for more detail.
+cleaner than using the `registerurl` template tag. See [partials](https://github.com/dimagi/commcare-hq/blob/master/docs/js-guide/integration-patterns.md#partials) above for more detail.
 
 
 ## Toggles and Feature Previews

docs/js-guide/migrating.md

@@ -20,7 +20,7 @@ These docs walk through the process of migrating a single page to RequireJS.
 
 ### Basic Migration Process
 
-Prerequisites: Before a page can be migrated, **all** of its dependencies must already be in external JavaScript files and must be using `hqDefine`. See above for details on moving inline script blocks to files, and see [module patterns](https://github.com/dimagi/commcare-hq/blob/master/docs/js-guide/blob/master/code-organization.md#module-patterns) for details on `hqDefine`. Also, pages that are not descendants of [hqwebapp/base.html](https://github.com/dimagi/commcare-hq/tree/master/corehq/apps/hqwebapp/templates/hqwebapp/base.html) cannot yet be migrated.
+Prerequisites: Before a page can be migrated, **all** of its dependencies must already be in external JavaScript files and must be using `hqDefine`. See above for details on moving inline script blocks to files, and see [module patterns](https://github.com/dimagi/commcare-hq/blob/master/docs/js-guide/code-organization.md#module-patterns) for details on `hqDefine`. Also, pages that are not descendants of [hqwebapp/base.html](https://github.com/dimagi/commcare-hq/tree/master/corehq/apps/hqwebapp/templates/hqwebapp/base.html) cannot yet be migrated.
 
 Once these conditions are met, migrating to RequireJS is essentially the process of explicitly adding each module's dependencies to the module's definition, and also updating each HTML page to reference a single "main" module rather than including a bunch of `<script>` tags:
 1. Add `requirejs_main` tag and remove `<script>` tags
@@ -131,7 +131,7 @@ Tactics that can help track down problems with the RequireJS build process, whic
 
 ## Moving away from classical inheritance
 
-See [our approach to inheritance](https://github.com/dimagi/commcare-hq/blob/master/docs/js-guide/blob/master/code-organization.md#inheritance). Most of our classical-style inheritance is a format than can be fairly mechanically changed to be functional:
+See [our approach to inheritance](https://github.com/dimagi/commcare-hq/blob/master/docs/js-guide/code-organization.md#inheritance). Most of our classical-style inheritance is a format than can be fairly mechanically changed to be functional:
 - In the class definition, make sure the instance is initialized to an empty object instead of `this`. There's usually a `var self = this;` line that should be switched to `var self = {};`
 - Throughout the class definition, make sure the code is consistently using `self` instead of `this`
 - Make sure the class definition returns `self` at the end (typically it won't return anything)