You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In versions before 0.6.0 you could specify a relative path for the jar file:plantumljar: "plantuml/plantuml.1.2020.17.jar"
In version 0.7.0 the path is resolved relative to the plugin's path, e.g. node_modules/gatsby-remark-plantuml so if you want a relative jar file you need to specify it as:
It would be good if this were either documented, or changed to make it relative to the project itself - gatsby only gives a very unhelpful error message, so it's quite hard to work out why this isn't working.
The issue seems to be in the path.resolve call, which now is relative to __dirname
The text was updated successfully, but these errors were encountered:
The tests indicate there should be an error, which I note is clearly a developer local path... not what I'd normally consider suitable...
`Error: Unable to access jarfile C:\\ide\\gatsby-remark-plantuml\\lib\\plantuml-does-not-exist.jar\r\n`
Are you not seeing similar errors in your output to indicate the path of the jarfile?
I don't know why __dirname was added, I haven't written any notes on that... oops.
As I'm the maintainer, I don't use the relative option, I just upgrade plantuml.
If you are using this option, can you work out what make sense?
Either relative to the gatsby project, or relative to the node module.
And then provide a contribution? with documentation
In versions before 0.6.0 you could specify a relative path for the jar file:
plantumljar: "plantuml/plantuml.1.2020.17.jar"
In version 0.7.0 the path is resolved relative to the plugin's path, e.g.
node_modules/gatsby-remark-plantuml
so if you want a relative jar file you need to specify it as:It would be good if this were either documented, or changed to make it relative to the project itself - gatsby only gives a very unhelpful error message, so it's quite hard to work out why this isn't working.
The issue seems to be in the path.resolve call, which now is relative to
__dirname
The text was updated successfully, but these errors were encountered: