Tune writing style checker for plugin compatibility and custom apps

[nkuehn]

• provides a local "raw" vale command that the config can be directly passed to. This proved more robust when using the VSCode plugin.
• adjust recommended VSCode workspace to use the config directly from the package to make transparent that it's not the same as an NPM version. Also allows for quicker local feedback in the editor when tuning the rules.
• add a few acronyms that are common in software development
• allow the "ZEIT" brand in acronymys (false negative, it's not an aconym).

[vercel]

This pull request is being automatically deployed with ZEIT Now (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://zeit.co/commercetools/commercetools-docs-kit/110d5vt3z
✅ Preview: https://commercetools-docs-git-nk-writing-style-for-custom-apps-ab0e79.commercetools.now.sh

[emmenko]

Thanks! We should also probably update the readme.

[emmenko]

We should be careful with this, as the symlinked binary name might conflict with other packages exposing such name.
We should try to use a more specific name.

[emmenko]

Or we don't expose the npm binary and just have a "proxy" bash script or something that points to the specific binary version.
I suppose this is mostly the case when you want to use it in e.g. VSCode.
With that also, we can read the vale version from the package.json and use it in the proxy script, instead of having the version hardcoded multiple times.

[nkuehn]

I'm renaming the symlink and adding it to the Readme. Forgot that you can install it globally and that would collide with a default vale installation.

[emmenko]

It's not just the global installation, but also the node_modules/.bin symlinks

[emmenko]

Have you considered my alternative proposal, of having a "proxy" script?

[nkuehn]

Yes, but the technical intent here is to get rid of any wrappers (for other reasons, too like keeping the color output).
is the new name ok?

[emmenko]

My point was that if we just need access to the vale binary for the vscode setup, I wouldn't put it in the npm binary list because we already have the commercetools-vale binary.

In vscode you just point the binary to

"vscode-vale.path": "${workspaceFolder}/node_modules/@commercetools-docs/writing-styleles/vale-bin",
"vscode-vale.configPath": "${workspaceFolder}/node_modules/@commercetools-docs/writing-styleles/.vale.ini",

The vale-bin then is just a proxy script to the downloaded binary version.

[nkuehn]

Yes, I got your point but I (as one of the actual users) do want to call it without going through a proxy script to get colored console output. Can you live with that fact? I wrote it in the above comment for a reason.

[emmenko]

I think you're still missing my point. The commercetools-vale stays as-is, no changes there. I assume that users will primarily use that binary, if they want to.

Now, regarding the second binary: my question (which you still haven't answered) is whether this binary is only supposed to be used for the VSCode plugin or are there any other use cases for which you (as a user) would need to use it directly, instead of using the commercetools-vale binary.

No hard feelings, I'm just trying to understand the requirements as it's still not clear to me.

[nkuehn]

PS: the plugin now works for me, too :-)

[emmenko]

Let’s move on with this. Thanks again for looking into it.

[emmenko]

Don't forget to assign the label, thanks