remark-lint: Multiple globally installed presets and plugins don’t work
Following the example in the README.md.
// example.md
* Hello
[World][]
// .remarkrc
{
"plugins": [
"remark-preset-lint-recommended",
["remark-lint-list-item-indent", false]
]
}
$ remark .
example.md
1:3 warning Incorrect list-item indent: add 2 spaces list-item-indent remark-lint
3:1-3:10 warning Found reference to undefined definition no-undefined-references remark-lint
The list-item-indent
rule should have been disabled, but it’s still active.
About this issue
- Original URL
- State: open
- Created 7 years ago
- Reactions: 3
- Comments: 39 (14 by maintainers)
I understand. But as you develop and add new modules this deduped state will not be guaranteed. you would have to delete
node_modules
and reinstall or runnpm dedupe
.It’s a working workaround indeed.
I’m not sure it’s the ideal approach though. It makes it really really hard to lint markdown that is not in a node project. All other linters (eslint, stylelint) do not rely on plugin/rule identity but on names, so this problem doesn’t happen. So they can be used globally with globally installed configs and plugin.
There is a difference between installing rules and activating, using them. The problem now is that a preset installs and activates a number of rules. A later bit of configuration should be able to switch rules on and off without actually installing them. If you enable a rule, but have not installed the rule, you should get a warning.
So my proposal would be: Let the plugin section deal with gathering the installed rules. Let a rule section, outside plugins, declaratively switch rules on and off. A handy option would be
which switches on all the rules of mentioned presets, which can be individually overridden by subsequent declarations. I think this is more like how eslint rules work.
An other thing: it would be nice if remark-stringify would look at the same options as the parser.
So here’s what’s going on:
remark-lint-maximum-line-length
is notremark-preset-lint-markdown-style-guide/node_modules/remark-lint-maximum-line-length
When I’m talking about deduping I mean the flatting that npm and yarn do automatically. A clean
npm install
creates that flattened state. Plugins load perfectly if you have that. Global installs don’t do that. You can read more about it in npm’s docs (search for--global-style
).I suggest using
remark-cli
globally, but don‘t store presets and plugins globally.Relying on module/rule name is the better solution, to not have conflicts with versions of the rule. Eslint does this too, and rules are named according to
${package}/${rule}
, and it works very well.I’m currently trying to use some presets together, and the one overwrites some rule of the other, and that’s fine. It’s only very strange how remark-lint is setup, as each preset needs to include
remark-lint
, making it too tightly coupled. A preset should define the rules, and have a peer-dependency onremark-lint
, no? It will make so much more sense. Presets should also have a peer-dependency on the plugins they use. Only in this way will versions be installed once with the one defined by the consumer. It is a bit more management for the consumer, but less fragile and then you have a good overview of the things you are using.Any update with this issue? I was trying configure stuff with
~/.remarkrc
and install plugins globally and got affected by the same issues raised by @pvdlg and @dirkroorda.I would suggest editing the title of this issue to make it more obvious the problem is related to globally installed plugins.
Also, I understand the proposed workaround of installing plugins locally in
~/node_modules
, but is there no plan to fix this properly?@wooorm, would that be too difficult to implement in the current codebase? Would you be against PRs in that direction?
No, it’s exactly because global mode doesn’t dedupe!
You can use global mode, but in that case, when reconfiguring plugins, you need to point to the deeper plugin! Global mode doesn’t flatten the tree, which is why it’s not suitable for this.
npm installs stuff differently in
~/.npm-packages
than in other places, so you can fix this by creating a normalnode_modules
somewhere, and use that for your plugins!Could you rub with
DEBUG="*" remark .
and post the results?This problem can occur if
remark-preset-lint-recommended
loads a differentremark-lint-list-item-indent
(such as if versions mismatch).