fix references

doc/src/manual/style-guide.md

@@ -346,7 +346,7 @@ This would provide custom showing of vectors with a specific new element type. W
 this should be avoided. The trouble is that users will expect a well-known type like `Vector()`
 to behave in a certain way, and overly customizing its behavior can make it harder to work with.
 
-## Avoid type piracy
+## [Avoid type piracy](@id avoid-type-piracy)
 
 "Type piracy" refers to the practice of extending or redefining methods in Base
 or other packages on types that you have not defined. In extreme cases, you can crash Julia

doc/src/tutorials/creating-packages.md

@@ -1,4 +1,4 @@
-# **5.** Creating Packages
+# [Creating Packages](@id creating-packages-tutorial)
 
 ## Generating files for a package
 
@@ -351,7 +351,8 @@ julia> write("test/runtests.jl",
 ## Compatibility on dependencies
 
 Every dependency should in general have a compatibility constraint on it.
-This is an important topic so there is a separate chapter about it: [Compatibility](@ref Compatibility).
+This is an important topic so there is a chapter in the package docs about it:
+[Compatibility](https://pkgdocs.julialang.org/v1/compatibility).
 
 ## Weak dependencies
 
@@ -452,7 +453,7 @@ It is only when the `Contour` package actually gets loaded that the `PlottingCon
 and provides the new functionality.
 
 If one considers `PlottingContourExt` as a completely separate package, it could be argued that defining `Plotting.plot(c::Contour.ContourCollection)` is
-[type piracy](https://docs.julialang.org/en/v1/manual/style-guide/#Avoid-type-piracy) since `PlottingContourExt` _owns_ neither the method `Plotting.plot` nor the type `Contour.ContourCollection`.
+[type piracy](@ref avoid-type-piracy) since `PlottingContourExt` _owns_ neither the method `Plotting.plot` nor the type `Contour.ContourCollection`.
 However, for extensions, it is ok to assume that the extension owns the methods in its parent package.
 In fact, this form of type piracy is one of the most standard use cases for extensions.