Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Changes to markdown config does not propagate. #664

Closed
kumorig opened this issue Jul 23, 2018 · 5 comments
Closed

Changes to markdown config does not propagate. #664

kumorig opened this issue Jul 23, 2018 · 5 comments
Labels
has workaround Has a workaround type: bug Something isn't working

Comments

@kumorig
Copy link

kumorig commented Jul 23, 2018

Bug report

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.

Version

0.12.0

Steps to reproduce

(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

What is expected?

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})

What is actually happening?

After the first build/dev any further changes to the markdown object in config.js has no effect..

Other relevant information

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: #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?

  • Your OS:
    Windows 10
  • Node.js version:
    8.3.11
  • Browser version:
    Version 67.0.3396.99 (Official Build) (64-bit)
  • Is this a global or local install ?
    vuepress is installed globally
  • Which package manager did you use for the install?
    [email protected]
@ulivz ulivz added type: bug Something isn't working has workaround Has a workaround labels Jul 25, 2018
ulivz added a commit that referenced this issue Jul 25, 2018
It's reported by #664, but #664 cannot be fixed fully since watching webpack config changes shouldn't be handled in VuePresss

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 muanully.

See: webpack/webpack#3153, webpack/webpack-cli#15
ulivz added a commit that referenced this issue Jul 25, 2018
It's reported by #664, but #664 cannot be fixed fully since watching webpack config changes shouldn't be handled in VuePresss

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.

See: webpack/webpack#3153, webpack/webpack-cli#15
@ulivz
Copy link
Member

ulivz commented Jul 25, 2018

Thanks for the reporting, and it's not an OS-related issue.

It's truly introduced by .cache-loader (dfdc00c) 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 0ad1a45, 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: webpack/webpack#3153, webpack/webpack-cli#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.

@brendanzab
Copy link

@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.

@kumorig
Copy link
Author

kumorig commented Aug 8, 2018

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!

@brendanzab
Copy link

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... 😅

@Enteleform
Copy link

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
has workaround Has a workaround type: bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants