Fix the fallback path to the l10n folder

[datho7561]

What does this PR do?

Change the relative fallback path of the l10n bundle so that it works even if the language client doesn't send the path in the initialization options.

What issues does this PR fix or reference?

If the language server client doesn't specify the location of the l10n folder, then the language server falls back to a path relative to the complied file. This path was wrong; server.js is in ./out/server/src/server.js, so the relative path of the l10n folder is ../../../l10n instead of ../l10n.

Is it tested? How?

1. Open vscode-yaml and comment out https://github.com/redhat-developer/vscode-yaml/blob/main/src/extension.ts#L134 so the language client doesn't specify where the l10n path is.
2. Run the extension and verify that the language features still work.

[datho7561]

I need to fix the tests done

[coveralls]

coverage: 83.956% (-0.02%) from 83.971%
when pulling 01ca741 on datho7561:fix-l10n-fallback-path
into 5215810 on redhat-developer:main.

[msivasubramaniaan]

LGTM

[lotheac]

@datho7561 as a distro packager (with very little js-specific experience): I find it a little surprising that the build now produces an out/ directory, but its contents depend on files outside of that out/ directory (ignoring library dependencies).

At least the Alpine package (which I maintain) and the Arch PKGBUILD are manually copying the l10n json directory into the distro package, and it's a bit of an extra step for packagers to figure out that it was wrong to assume that the build output directory contains everything necessary.

I wonder if you would consider copying the l10n json files to a location in the out/ directory instead?

(and sorry for being so slow with this comment that this was merged in the meantime :)

[datho7561]

If we copy the l10n into out, then there will be two copies of l10n in the published npm package, one in ./l10n and one in ./out/l10n.

JS projects have very freeform build processes, unlike Maven projects or cargo projects. You'll need to understand the build process in order to repackage this package correctly, especially if you are adding other steps like bundling the code into one file.

[p-spacek]

Hey @datho7561, I am also a little bit worried about this change
the 'static' path '../../../l10n' works ok for local build when you have 'yaml-language-server' located next to this 'vscode-yaml' project in filesystem. https://github.com/redhat-developer/vscode-yaml/blob/4b1730412b5a6bf82f0bc23f6665db8904bf4c21/src/extension.ts#L116

if you build the project with webpack and link the package, the l10n folder is missing
if you compile YLS by

• 'yarn compile', the structure is also a little bit different (out/server/src/yamlServerInit)
• 'yarn compile:umd', the structure is also a little bit different (lib/esm/yamlServerInit)

So note that,

• if you clone vscode-yaml repo from scratch and try to build it, the extension will fail, because '../yaml-language-server/l10n' is not in your filesystem automatically
• if you build extension with webpack, the fallback path refers outside of the extension to ''/Users/john/.vscode/l10n/bundle.l10n.json''

[datho7561]

Yeah, that's not good. The fallback path is pretty useless except for when developing the extension with yaml-language-server cloned and in the same folder. The correct path needs to be passed in from the client during initialization otherwise nothing works as expected.

I can't get vscode-yaml to launch if yaml-language-server isn't in the same folder anyways.

What actions can we take to address this? I guess making the directory structures for UMD, ESM, and whatever the default build is the same would help.

[datho7561]

Also why TF is tsconfig.json marked as executable?

[datho7561]

Some history on the directory structure: #305

I want to move the cjs code (the output of npm run compile) to under ./lib/cjs (eg. ./lib/cjs/server.js) however this would mean getting rid of ./out/server/src/, which apparently might break some clients. (It'll break vscode-yaml but we can fix that).

But really, I think most clients launch yaml-language-server through the binary and communicate through stdio. I don't know how many people/projects we will actually break. It will be breaking API, so we might need to call the release 2.0.0?

Also, realistically we don't need both the cjs and umd output, the umd output should be sufficient.