This will allow `/deployment` to be the "basics" page for deployment and
avoid re-using the term "Best Practices" in a section that isn't inside the
"best practices" portion of the guide.
As determined in
https://github.com/renovateapp/config-help/issues/23#issuecomment-377202632,
it seems that it's not possible to have this sort of inherited
configuration. It's possible that when I first introduced this behavior
that this behavior was on its way out (and the breaking change in Renovate
v11 on its way in).
Luckily, Renovate's shared configuration option still allows this to be
relatively painless and our `apollo-docs` shared configuration[0] does most
of the heavy lifting here so there won't be too much Renovate toe-stepping.
If this works well in the `apollo-server` repository, I'll transplant this
change to the other docs repositories[1].
[0] https://github.com/apollographql/renovate-config-apollo-docs
[1] https://github.com/meteor/hexo-theme-meteor
Many of these comments are unhelpful anyway and deserve to be maintained in the
"doc docs" (yes, docs for the docs), which live at https://github.com/apollographql/docs-docs/.
This the reason for this unneeded dependency traces back to the `api-box` on
https://github.com/meteor/docs, though its dependency hasn't been necessary on
any other docs deployment, including this one, since then.
I can't find any evidence in any docs deployment that `lodash` ever needed to
be a direct dependency. It's possible that this is an artifact that once lived
in an early stage of the docs and just propagated out as a result of making new
docs from old docs repositories. The `theme-example` application should help
set better precedence for this in the future.
Rather than developing the theme on individual docs deployments, that work
should now be done on the theme repository[0] and the example doc
deployment[1] since those repositories contain the infrastructure for testing
and deploying changes across all docs properties. More information on
developing the theme can be found on those repository's `README.md`s.
[0] https://github.com/meteor/hexo-theme-meteor
[1] https://github.com/meteor/theme-example
While I'm aware of the need for the `showdown` package for rendering some
content on the Meteor Docs, I'm not aware of any Apollo repository that uses
it. I've searched through the source, and cannot find any usage.
If there is a repository that uses it directly (in its `scripts/` directory),
it should be switched to using a plugin, which can explicitly declare
`showdown` as a dependency, rather than depending on it at the root of the
repository. (This is how `hexo-typescript-api-box` does it on the
`apollo-client` docs, which has correctly removed the direct dependency.)
Luckily, these repositories now have tests so if any of these fail, we should
know pretty easily and be able to add the dependency back to just those that
need it.
Generators are used for generating additional content in Hexo. While these
are great for making a blog (for example, `hexo-generator-index` to put all
your blog posts on an index page, `hexo-generator-tag` to keep a page updated
with all your trending blog tags, and `hexo-generator-archive` if you want to
store your aging content somewhere where nobody will find it), they don't seem
to be at all necessary for our purposes, which are documentation.
Unfortunately, they are in the default skeleton of a new Hexo project and they
don't seem to have ever been removed from our non-blog docs deployments,
despite the fact that they seem unnecessary.
In an effort to drastically reduce the overhead of maintaining these docs
deployments, I'm removing these as "unnecessary" until proven otherwise.
For reasons unbeknownst to me, the changes below were only being complained
about in the CI environment but _not_ when I ran `npm run lint` locally.
It seems partially related to the OS its ran on, so I imagine there might be
some other sub-dependency at play here. In an effort to fix this, I just
spawned a Ubuntu docker image, checked out this repository and ran the same
`npm run lint`. This produced identical results to Travis, so I ran
`npm run lint-fix`, then saved the `git diff` results and have applied this
locally.
This should allow us to re-enable `prettier` in CI, though I have plans to
separate that from the actual `npm test` runs. This should result in a better
workflow for managing PRs.
* docs: Use `devDependencies` instead of `dependencies`.
It's safe to mark all dependencies of this theme as 'dev' dependencies, as
none of them are needed to be installed in a production setting.
This was done automatically, so in some cases, this merges existing
`devDependencies`, and may also have added a missing `nodemon` `devDependency`
in cases where it was missing. In other cases, this commit may not have
made such a change.
* docs: Remove _config.yml options now covered by global theme config.
* docs: Add `_multiconfig.yml`, a build artifact, to docs `.gitignore`.
* docs: Use theme from npm, rather than submodule, using `chexo`.
The theme which the docs in this repository are based on
([`hexo-theme-meteor`](https://github.com/meteor/hexo-theme-meteor)) has been
published to npm.
Additionally, most of the configuration which was once present in this
repository's `_config.yml` file, has been moved into an Apollo-centric theme
configuration npm,
[`apollo-hexo-config`](https://www.npmjs.com/package/apollo-hexo-config) (and
similarly, [GitHub](https://github.com/apollographql/apollo-hexo-config)).
The theme bundled in this npm is a converged version of the two `apollo`
and `master` branches on the `hexo-theme-meteor` repository, which is a result
of the work undertaken in https://github.com/meteor/hexo-theme-meteor/pull/51.
Lastly, this makes use of a new `chexo` npm which acts as a wrapper for `hexo`
but permits the use of an inherited configuration from npm, rather than a
statically defined CLI file parameter (previously with `--config a,b`).
* docs: Upgrade Hexo generator/tag/server dependencies.
* docs: Add missing `meteor-theme-hexo` package.
This was apparently missed, only on this repository (???) in my automated
commits, probably due to my own error.
