Any markdown-options in config.js seems to get cached the first time you use vuepress build or vuepress dev and and further changes make no difference. Not even removing markdown from the config has any effect.
0.12.0
(In windows cmd):
mkdir docs\.vuepress
echo # title > docs\README.md
echo module.exports = { markdown: { anchor: { permalinkSymbol: 'a' } } }; > docs\.vuepress\config.js
vuepress dev docs // Works ( shows 'a' as permalinkSymbol )
echo module.exports = { markdown: { anchor: { permalinkSymbol: 'b' } } }; > docs\.vuepress\config.js
vuepress dev docs // Still shows 'a' as permalinkSymbol
Changes to markdown: {...} in config.js should update immediately (HMR) using vuepress dev, or at the very least the next time your restart dev or use build. This is expected because that's how other changes in config.js update. (For example: themeConfig:{search:false})
After the first build/dev any further changes to the markdown object in config.js has no effect..
I can force update by deleting the cache folder at (%appdata%\nvm\v8.11.3\node_modules\vuepress\node_modules\.cache)
I would guess this problem is the reason to issues such as this: https://github.com/vuejs/vuepress/issues/526
And if this is a windows only issue, I'd like to point out something that may or may not be related:
If I run vuepress from c:\projects\test\ instead of C:\projects\test\ (notice upper case C) then I get the following warning:
WARNING in C:/Users/user/AppData/Roaming/nvm/v8.11.3/node_modules/vuepress/node_modules/vue-loader/lib/runtime/componentNormalizer.js
There are multiple modules with names that only differ in casing.
This can lead to unexpected behavior when compiling on a filesystem with other case-semantic.
Use equal casing. Compare these module identifiers:
* C:\Users\user\AppData\Roaming\nvm\v8.11.3\node_modules\vuepress\node_modules\vue-loader\lib\runtime\componentNormalizer.js
Used by 32 module(s), i. e.
C:\Users\user\AppData\Roaming\nvm\v8.11.3\node_modules\vuepress\node_modules\cache-loader\dist\cjs.js??ref--0-0!C:\Users\user\AppData\Roaming\nvm\v8.11.3\node_modules\vuepress\node_modules\vue-loader\lib\index.js??vue-loader-options!C:\Users\user\AppData\Roaming\nvm\v8.11.3\node_modules\vuepress\lib\app\components\OutboundLink.vue
* c:\Users\user\AppData\Roaming\nvm\v8.11.3\node_modules\vuepress\node_modules\vue-loader\lib\runtime\componentNormalizer.js
Used by 2 module(s), i. e.
C:\Users\user\AppData\Roaming\nvm\v8.11.3\node_modules\vuepress\node_modules\cache-loader\dist\cjs.js??ref--1-0!C:\Users\user\AppData\Roaming\nvm\v8.11.3\node_modules\vuepress\node_modules\vue-loader\lib\index.js??ref--1-1!C:\Users\user\AppData\Roaming\nvm\v8.11.3\node_modules\vuepress\lib\webpack\markdownLoader.js??ref--1-2!c:\projects\test3\docs\README.md
@ C:/Users/user/AppData/Roaming/nvm/v8.11.3/node_modules/vuepress/node_modules/vue-loader/lib/runtime/componentNormalizer.js
@ C:/Users/user/AppData/Roaming/nvm/v8.11.3/node_modules/vuepress/lib/app/components/OutboundLink.vue
@ C:/Users/user/AppData/Roaming/nvm/v8.11.3/node_modules/vuepress/lib/app/app.js
@ C:/Users/user/AppData/Roaming/nvm/v8.11.3/node_modules/vuepress/lib/app/clientEntry.js
@ multi C:/Users/user/AppData/Roaming/nvm/v8.11.3/node_modules/vuepress/lib/app/clientEntry.js
Things seems to run fine despite the warning, I'm just suggesting that if vuepress has a problem with paths in windows, maybe the same is true about vuepresses cache handling?
Windows 108.3.11Version 67.0.3396.99 (Official Build) (64-bit)vuepress is installed globally[email protected]Thanks for the reporting, and it's not an OS-related issue.
It's truly introduced by .cache-loader (https://github.com/vuejs/vuepress/commit/dfdc00c8ba5e89ee66a9539bb9b4d4fff639d904) and we don't include the siteConfig.markdown, so even if you have modified the makrdown config, you will not see the updated output.
I have fixed this issue at 0ad1a4590fb69ac2074b5bdbf240d1eb9f596f1e, but that's not a complete fix for this issue, we still cannot reach HMR, because we cannot watch webpack config changes for now. (See: https://github.com/webpack/webpack/issues/3153, https://github.com/webpack/webpack-cli/issues/15)
VuePress can only ensure that when user changes the markdown config, the cache identifier will be updated, so user needn't to clean the ./node_modules/.cache manually.
@ulivz: Is your change meant to re-render the markdown when you alter siteConfig.markdown.config? I have a bunch of stuff in there, including custom language highlighting and KaTeX macros: https://github.com/pikelet-lang/pikelet-site-vuepress/blob/e63e18d0996961f9fae0f959bd81faefe697fb66/docs/.vuepress/config.js#L53-L167
When I update them the page refreshes, but the content doesn't change. I instead have to restart the dev server and alter some of the surrounding text to get the changes to propagate.
edit: nevermind, I can't read (as usual). Yes, you have to restart the dev-server and update the md-file in question (That's what @ulivz HMR comment is about). Before 0.13.0 you had to manually remove your cache-folder to see any changes so tons of improvement but not perfect yet.
I can understand that HMR might be unfeasible, but perhaps it could be possible to invalidate existing rendered markdown-cache after changes to the markdown-config? I mean who would want to keep their old output after making changes that (almost certainly) would change that output? (it would make my life a little little bit easier anyway!) Thanks for the hard work @ulivz!
Oh right, the current behaviour is definitely an improvement from that, even if it is still a little frustrating! Thanks for the fix @ulivz! Is there another issue tracking this problem? I wasn't able to find one... 馃槄
@ulivz
VuePress can only ensure that when user changes the markdown config, the cache identifier will be updated, so user needn't to clean the ./node_modules/.cache manually.
I'm currently using v1.0.0-alpha.47 and have found that I still need to clean the cache manually before running vuepress dev docs. I'm working on a project-specific markdown-it plugin and the only way to propagate changes is to clear the cache or make an arbitrary edit to the markdown file as @brendanzab mentioned.