Doesn't like AWS CloudFormation templates about yaml-language-server

[JPinkney]

This is available in 0.0.7 of the language server!

[esn89]

I have something like this set up:

				"customTags": [
					"!fn",
					"!And",
					"!If",
					"!Not",
					"!Equals",
					"!Or",
					"!FindInMap sequence",
					"!Base64",
					"!Cidr",
					"!Ref",
					"!Ref Scalar",
					"!Sub",
					"!GetAtt",
					"!GetAZs",
					"!ImportValue",
					"!Select",
					"!Split",
					"!Join sequence"
				]

But I am still getting this error: https://i.imgur.com/gj32GKq.png

[ffxsam]

@JPinkney YOU, SIR... are a hero.

[richardmaltais]

Hey, sorry to re-open an old issue, but I can't make the server to work with AWS CloudFormation. Is there a specific setting to input somewhere?

I'm on VS Code and I tried to reference to a schema, tried different ways, but it just doesn't work.

Thank you in advance!

[esn89]

Bump. I was wanting to know if there is a setting I have to do

[JPinkney]

You have to manually add custom tags to the yaml.customTags setting. Here is the explanation from readme: yaml.customTags: Array of custom tags that the parser will validate against. It has two ways to be used. Either an item in the array is a custom tag such as "!Ref" or you can specify the type of the object !Ref should be by doing "!Ref Scalar". For example: ["!Ref", "!Some-Tag Scalar"]. The type of object can be one of Scalar, Sequence, Mapping, Map.

There are a few issues with custom tags that are known: #77.

From the snippet posted above I believe it would be
yaml.customTags: [
"!Sub"
]

or

yaml.customTags: [
"!Sub scalar"
]

(it defaults the type to scalar so you don't have to specify the scalar for the property)

[esn89]

So all I have to do is, for each custom tag I have, I add them, AND a version with them with the word "Scalar" next to it?

[JPinkney]

"!Ref",
"!Ref Scalar",

You might be running into the issue in #77 (i'm not sure on first glance).

However, those two tags mean the same thing and the type should be lower cased (if you include it). You should only have to do either "!Ref" or "!Ref scalar".

If there still is an error after that can you open a new issue just to make sure everything is logged so it doesn't get forgotten!

[esn89]

Hi @JPinkney,

Thanks for the help, so far I've kept it lean and only used the !Ref tag at the moment.

I have the langserv set up like so:

		"yaml": {
			"module": "/Users/esn89/.config/coc/extensions/node_modules/yaml-language-server/out/server/src/server.js",
			"filetypes": ["yaml"],
			"cwd": "./src",
			"settings": {
				"format.enable": true,
				"validate": true,
				"completion": true,
				"customTags": [
					"!Ref scalar"
				]
			}
		}

And I still have the same error of:
[yaml] [E] unknown tag <!Ref>

I am happy to say that the format settings, validate settings and completion works.
Am I doing something obviously wrong?

[JPinkney]

It looks right to me. I'm not sure if the customTags isn't being synced or whats going on because its working through VSCode:

[esn89]

Thanks for your reply.

I am wondering if it could be a result of using a different client?

Right now I am using:
https://github.com/neoclide/coc.nvim/

And my entire set up looks like this:

	"languageserver": {
		"yaml": {
			"module": "/Users/esn89/.config/coc/extensions/node_modules/yaml-language-server/out/server/src/server.js",
			"filetypes": ["yaml"],
			"cwd": "./src",
			"settings": {
				"format.enable": true,
				"validate": true,
				"completion": true,
				"customTags": [
					"!Ref scalar",
					"!GetAtt",
					"!FindInMap sequence",
					"!FindInMap"
				],
				"schemas": {
					"https://raw.githubusercontent.com/awslabs/goformation/master/schema/cloudformation.schema.json": "/*"
				}
			}

		}
	}

[JPinkney]

I'm not entirely sure, does turning off and on validation/completion settings etc work? Also for custom tags you cant have both !FindInMap sequence and !FindInMap currently. It will result in error (see discussion in #77 (comment) for more info)

[esn89]

Alright, so I have removed !FindInMap sequence turn off validation and completion (all set to false), however, I am still getting "[yaml] [E] unknown tag <!Ref>"

As this comes from the server, this should be client agnostic, yes?

[JPinkney]

As this comes from the server, this should be client agnostic, yes?

Correct, I was just trying to see whether the settings synced when you turned off validation and completion. When validation is false you shouldn't be getting any errors at all (regardless of if they exist or not). Do you know if there's any way to see the language server trace from that client?

[esn89]

I will see if I can make that happen.

[esn89]

So it turns out that my customTags: was in the wrong place. For my coc.nvim client, I have to do it like this to make it work:

	"yaml.schemas": {
		"https://raw.githubusercontent.com/awslabs/goformation/master/schema/cloudformation.schema.json": "/*"
	},
	"yaml.customTags": [
		"!Ref",
		"!GetAtt",
		"!fn",
		"!And",
		"!If",
		"!Not",
		"!Equals",
		"!Or",
		"!FindInMap sequence",
		"!Base64",
		"!Cidr",
		"!Sub",
		"!GetAZs",
		"!ImportValue",
		"!Select",
		"!Split",
		"!Join sequence"
	],
	"languageserver": {
		"yaml": {
			"module": "/Users/esn89/.config/coc/extensions/node_modules/yaml-language-server/out/server/src/server.js",
			"filetypes": ["yaml"],
			"cwd": "./src",
			"settings": {
				"format.enable": true,
				"validate": true,
				"completion": true
			}
		}
	}

Now it works. :D

My second question now is regarding the schemas, I have added the schema's as per:
https://raw.githubusercontent.com/awslabs/goformation/master/schema/cloudformation.schema.json

For CloudFormation, and at the moment it isn't doing anything to the file. My guess is that by adding this schema, it will check for the valid type and whether or not the keys are valid.

I have been putting in random values in my yaml file, typos on purpose and the wrong types. However, it doesn't seem to detect errors. Do I have the right impression of schemas? IS that what they're supposed to do?

[JPinkney]

hmm, after setting yaml.schemas are you able to activate any of the other features that rely on a schemas (such as autocomplete)?

My only guesses are that the schema is slow to load, its not being set, or the schema may not catching everything. Can you try out

AWSTemplateFormatVersion: False

and tell me if it errors

Do I have the right impression of schemas? IS that what they're supposed to do?

Yes, depending on how well built the schemas are

[esn89]

Yup, I have reactivated them:

	"yaml.schemas": {
		"https://raw.githubusercontent.com/awslabs/goformation/master/schema/cloudformation.schema.json": "/*"
	},
	"yaml.customTags": [
		"!Ref",
		"!GetAtt",
		"!fn",
		"!And",
		"!If",
		"!Not",
		"!Equals",
		"!Or",
		"!FindInMap sequence",
		"!Base64",
		"!Cidr",
		"!Sub",
		"!GetAZs",
		"!ImportValue",
		"!Select",
		"!Split",
		"!Join sequence"
	],
	"languageserver": {
		"yaml": {
			"module": "/Users/esn89/.config/coc/extensions/node_modules/yaml-language-server/out/server/src/server.js",
			"filetypes": ["yaml"],
			"cwd": "./src",
			"settings": {
				"format.enable": true,
				"validate": true,
				"completion": true
			}
		}
	}

And with your suggestion of setting the flag to false, it doesn't seem to pick up any errors. In one of my resources like RDS::DBInstance, I put:
FOOOOOO: "bar" as a property and that, I would assume would trigger an error.
Could it be a issue with the /*?

[JPinkney]

Could it be a issue with the /*?

The /* is just telling the schema to map to all yaml files.

setting the flag to false

By flag do you mean AWSTemplateFormatVersion: False?

In one of my resources like RDS::DBInstance I put:
FOOOOOO: "bar" as a property and that, I would assume would trigger an error.

Can you post a snippet of that part its hard to diagnose without being able to see it. (I have no knowledge of AWS CloudFormation so I can only look at the schema and compare it with what I think it is doing).

Currently, can you trigger an error at all doing anything?

[esn89]

Sure thing, let me show you:
https://i.imgur.com/8SG2z3G.png

Here is a picture of my vim with this.

And the corresponding config is in my previous post, I haven't changed anything.

[JPinkney]

I might have to actually go in and install everything to see if I can get it working, because I'm not exactly sure why the errors aren't showing. On VSCode I get this:

[esn89]

Correct that is what it's supposed to happen, but it isn't what I am seeing. So it is working for you. Gah!!

You also have validation, completion and format installed?

I can give you the instructions to get this up running real quick (if you need/want):

1. grab neovim
2. install vim-plug into your neovim
3. install coc.nvim
4. install the coc-yaml for coc.nvim: :CocInstall coc-yaml
5. try my configuration file for coc.nvim. :CocConfig and paste my config:

{
	"coc.preferences.diagnostic.errorSign": " ",
	"coc.preferences.diagnostic.warningSign": " ",
	"coc.preferences.diagnostic.infoSign": " ",
	"coc.preferences.diagnostic.hintSign": "",
	"yaml.schemas": {
		"https://raw.githubusercontent.com/awslabs/goformation/master/schema/cloudformation.schema.json": "/*"
	},
	"yaml.customTags": [
		"!Ref",
		"!GetAtt",
		"!fn",
		"!And",
		"!If",
		"!Not",
		"!Equals",
		"!Or",
		"!FindInMap sequence",
		"!Base64",
		"!Cidr",
		"!Sub",
		"!GetAZs",
		"!ImportValue",
		"!Select",
		"!Split",
		"!Join sequence"
	],
	"languageserver": {
		"yaml": {
			"module": "/Users/esn89/.config/coc/extensions/node_modules/yaml-language-server/out/server/src/server.js",
			"filetypes": ["yaml"],
			"cwd": "./src",
			"settings": {
				"format.enable": true,
				"validate": true,
				"completion": true
			}
		}
	}
}

[JPinkney]

I think I may have found the issue. I'm still debugging but it looks like the trace is yielding this:

Which doesn't make sense at all. The schema is in a mangled format and thats probably why ?

EDIT: So I think I figured it out but i'm not really sure how to fix it. In neovim if you don't escape the dots inside the schema url then you get that mangled path (like above) but if you do you get:

because its trying to load a url with escaped dots.

[esn89]

What would happen if in the first picture you add dots to the broken down url, like:

"schemas": {
"https://raw." {
"githubusercontent." {
..... .....

The URL definitely does look mangled. So is this a behavior of coc?

[JPinkney]

I'm not sure if its a behaviour of coc or something else but I don't think its an issue with the language server itself (because it only tries to interpret that mangled URL and can't). In VSCode for example we would get:

without having to escape the dots or anything.

I'm not sure if it helps at all but these were the settings I was using.

{
          "yaml.customTags": [
                  "!Ref",
                  "!GetAtt",
                  "!fn",
                  "!And",
                  "!If",
                  "!Not",
                  "!Equals",
                  "!Or",
                  "!FindInMap sequence",
                  "!Base64",
                  "!Cidr",
                  "!Sub",
                  "!GetAZs",
                  "!ImportValue",
                  "!Select",
                  "!Split",
                  "!Join sequence"
          ],
          "languageserver": {
                  "yaml": {
                          "module": "/Users/joshpinkney/.config/coc/extensions/node_modules/yaml-language-server/out/server/src/server.js",
                          "filetypes": ["yaml", "yml"],
                          "args": ["--stdio"]
                  }
          },
          "yaml.hover":true,
          "yaml.validate": true,
          "yaml.trace.server": "verbose",
          "yaml.schemas": {"https://raw\.githubusercontent\.com/awslabs/goformation/master/schema/cloudformation\.schema\.json": "/*"
          }

[JPinkney]

Interestingly enough the json language server does not run into this issue (although they use a slightly different way of configuring their schemas)

[esn89]

So then for the json language server, and then json schema this works.......would rule out neovim, yes?

[JPinkney]

No, the problem is whatever is sending the requests to the language server is messing up the URL in the workspace/didChangeConfiguration request. JSON language server has a different way of setting up the schemas that doesn't trigger the errors. Actually now that I think about it, I think whats causing the issue is that they're splitting yaml.schemas and then splitting everything with a period after that so it results in the split up URL below, instead of preserving it.