Trouble Building Website #8
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Hi, Lezer looks amazing! Thank you for building it!
Last week I began work on a tool for creating programming languages, and selected Lezer for generating parsers.
I have found the reference manual to be very useful, but a bit long. And so I cloned this repository with the intention of adding a table of contents to it, which would let me jump straight to the relevant class when I wanted to look something up instead of scrolling around a bunch.
When I ran the documented build steps:
I encountered this error:
I realised this error occured because what was on NPM didn't match what was on GitHub, and
npm installwas getting the wrong stuff. I remediated the error like so:I then had to repeat this for
@lezer/lrand@lezer/generator. I believe either the NPM packages should be modified to include the dependencies for the website, or this link step should be documented.After linking the dependencies and re-running
node src/index.jsI encountered this error:I attached a debugger to
node_modules/builddocs/src/builddocs.js:137to take a closer look:Here are the relevant variables as they're defined at the breakpoint:
It appears that
maybeLinkTypeexpectsitems.Parserto be defined, but it is not. It is interesting to note, however, thatitems.LRParseris defined. When I looked at the changelog for @lezer/lr, I noticed version 0.15.0 changed the name ofParsertoLRParserand I believe this change broke the build process for the website.At this point, I decided to report my findings rather than continue. Hope this helps, and that we can get this fixed. 🙂
Oh, right, good point about the npm packages not having the change log or the sources.
Parseris now defined in@lezer/common, and the files build fine on my machine. Could be some kind of pathname confusion—are you on Windows by any chance?It was indeed pathname confusion! Not because I'm using Windows (I'm on Linux) but because of how
npm linkworks. This command creates a symbolic link, and these links are currently poorly handled bybuildref.This check in particular yields false negatives:
For the following cases:
I fixed the issue on my computer like so (using
fs.realpathSync):With this change the check passes for the relevant cases:
I was then able to run
node src/index.jswithout issue. I have created a pull request for this change.