VFileMessage generates invalid position if no position is given

[remcohaszing]

Initial checklist

• I read the support docs
• I read the contributing guide
• I agree to follow the code of conduct
• I searched issues and couldn’t find anything (or linked relevant results below)

Affected packages and versions

3.1.2

Link to runnable example

No response

Steps to reproduce

import { VFileMessage } from 'vfile-message'

const message = new VFileMessage('reason')

console.log(message.position)

Expected behavior

The message position is undefined.

According to the type definitions it’s optional, but currently it’s always set.

Actual behavior

The message position is a unist position, but the start and end line and column are set to null.

According to the unist types, start and end line and column can’t be null.

This causes various type errors. For example:

• No type errors should be suppressed in https://github.com/vfile/vfile-message/blob/main/index.js#L28-L30
• This check should not be necessary: https://github.com/unifiedjs/unified-language-server/blob/main/lib/index.js#L70-L74

This test explicitly asserts the incorrect behaviour:

vfile-message/test.js

Lines 63 to 66 in e5e87f2

	t.deepEqual(m1.position, {
	start: {line: null, column: null},
	end: {line: null, column: null}
	})

Affected runtime and version

node@18.8.0

Affected package manager and version

npm@8.17.0

Affected OS and version

Pop!_OS 22.04

Build and bundle tools

No response

[wooorm]

I think that’s just unist types not matching reality.

Particularly I think your second link, https://github.com/unifiedjs/unified-language-server/blob/main/lib/index.js#L70-L74, is always a good idea. We’re dealing with users here, and should expect some garbage. Not everyone uses TS. And even if TS is used, NaN could still be set. Or floats. Or floating point math could result in weird things?
I’d be more in favor of tools like unistPointToLspPosition to, at runtime, check whether values actually match what TypeScript says they do (same as syntax-tree/unist-util-lsp#1 (comment))

position could be null if someone subclasses VFileMessage without calling the constructor. It’s set to null here:

vfile-message/index.js

Line 185 in e5e87f2

VFileMessage.prototype.position = null

[remcohaszing]

The unist types match the specification for Position and Point accurately. A Position has a required start and end point and an optional indent. A Point has a required line and column of type number and an optional offset. vfile-message doesn’t follow this specification.

I won’t argue defensive programming is a good idea. People can indeed pass in incorrect data. But I do believe that official unified utilities shouldn’t create incorrect data.

[wooorm]

The code is there to make things easier before ? was in JS.
It’s there to make defensive coding easier.
It wasn‘t really meant to exactly match unist, because it’s not a node. And this can also represent a single point instead of two points (position). This project can’t match unist when only one point is given?
Other than that, the downside of going with types is that it might break some folks. 😬

[wooorm]

Friendly ping! :)

[remcohaszing]

I think we’re on the same line that currently VFileMessage#position is incorrectly typed as a unist Position.

At this point, VFileMessage#position can never be null. I don’t think we should take subclassing into account. Technically a subclass could change any property to anything, even without subclassing a user could change any value to anything.

The code is there to make things easier before ? was in JS.

But this comes at the cost that checking if(message.position) {} won’t work. Also it would be convenient to be able to pass message.position into utilities that accept unist positions. If it would be typed correctly now, TypeScript will no longer allow this.

Also now that the oldest supported Node.js version supports optional chaining, perhaps this is a good time to change it. I think it would also be nice timing to combine this with a major unified release (which is necessary because of unifiedjs/unified#202)

[wooorm]

The main problem I believe is that this project accepts a single point and exposes that information. The utilities typically support that starting point too as far as I am aware.

[remcohaszing]

Is there any particular reason start and end in a position may not be the same (shallow copy)?

[wooorm]

Interesting idea. Positions are supposed to be ranges. E.g., the end point of a position in the whole document, if it were a starting point, would be a point outside the document.

• say a was the whole document, it could be represented as a whole as 1:1-1:2 (0-1)
• the point 1:1 (0) points to the byte/character a
• the point 1:2 (1) is EOF

In micromark/markdown-rs, events are never empty. This is carried through to mdast as well, and I believe every mdast/hast/nlcst/xast utility follows it too

[remcohaszing]

This reminds me of the way Monaco editor handles TypeScript diagnostics. TypeScript text spans use the format { start: number, length: number }. As can be seen here, TypeScript can return a text span with a length of zero, but when rendering a squiggly line to display the error, the editor requires a minimal length of 1 character to underline.

I think this applies the exact same way in unist, or any text format. A text range can have a length of 0 characters, but the best way to display a range of length 0 is often to point to the character at that index.

[wooorm]

But then you’re suggesting to not support points at all, that users should pass a position of (pseudocode) start: start, end: start + 1?

[remcohaszing]

No, I suggest that a user can use:

vfile.message('hello', { line: 1, column: 1 })
assert.equal(vfile.position, { start: { line: 1, column: 1 }, end: { line: 1, column: 1 } })
assert.ok(vfile.position.start !== vfile.position.end)

But tools such as unist-util-stringify-position should be able to handle this:

import { stringifyPosition } from 'unist-util-stringify-position'

assert.equal(stringifyPosition({ start: { line: 1, column: 1 }, end: { line: 1, column: 1 } }), '1:1')
assert.equal(stringifyPosition({ start: { line: 1, column: 1 }, end: { line: 1, column: 2 } }), '1:1-1:2')

Although it might look less nice, I don’t really see any practical problems with the following representation:

assert.equal(stringifyPosition({ start: { line: 1, column: 1 }, end: { line: 1, column: 1 } }), '1:1-1:1')

[wooorm]

I still feel a bit weird about positions having the same start and end points. It feels like that shouldn’t occur. It feels “wrong”.

but when rendering a squiggly line to display the error, the editor requires a minimal length of 1 character to underline.

That’s a bit in line with what I feel as “wrong”. Same start and end is really empty. No line rendered.

Maybe I’m on my own here though, or have to get used to it?