Base path is not auto-set to "/" (default) causes ENOENT: no such file or directory

[aaronmallen]

given the following configuration:

{
  "src": [
      {
        "my-lib": [
          "./src/**",
          "!./src/errors/**"
        ]
      },
      "./CHANGELOG.md",
      "./CODE_OF_CONDUCT.md",
      "./CONTRIBUTING.md",
      "./docs/**/*.md"
    ],
  "dest": "./.docma",
  "app": {
    "title": "MyLib",
    "entrance": "content:readme",
    "server": "github",
    "routing": "path"
  }
}

images in the left navigation begin to break and terminal errors are logged:

Error: ENOENT: no such file or directory, stat '$MY_PROJECT/.docma/api/img/tree-parent.png'
Error: ENOENT: no such file or directory, stat '$MY_PROJECT/.docma/api/img//tree-folded.png'
Error: ENOENT: no such file or directory, stat '$MY_PROJECT/.docma/api/img/tree-parent.png'

This appears to be related to setting app.routing to "path" as setting it back to "query" seems to resolve the issue.

[onury]

Just try adding "base": "/" for app configuration.

[aaronmallen]

Shouldn't it already be that since I don't have it defined and that's the default value according to the documentation?

[onury]

Right. I'll fix that with the next release.

Should I assume setting the base resolved your issue?

[aaronmallen]

At first glance that appears to be the case yes, however I should highlight that this isn't consistently reproducible (i.e. refreshing the page also appeared to fix it until the next build run)

[onury]

I think that's might be because on the first load the initial page is redirected by the SPA and then you hit reload with the new route. Is that the case?

[aaronmallen]

Yeah actually it appears that applying "base": "/" does completely fix the issue, I just did 3 rebuilds in a row without seeing the images break. Now if I could just get you to make JSDoc work nicely with multi file libs I'd be in doc heaven 😂 Awesome tool btw thank you so much for this library.

[onury]

You're welcome.

Now if I could just get you to make JSDoc work nicely with multi file libs I'd be in doc heaven

How do you mean? Docma already supports grouping multiple JS files documented under the same route and you can have multiples of that too, if that's what you mean.

[aaronmallen]

Its not a docma issue really, I don't like having to explicitly name functions in certain situations when using ecma 6. For example:

// index.js
import Component1 from './component-1.js'
import Component2 from './component-2.js'
/** 
 * The primary module
 * @module MyLib
 *
 */
export default {
  Component1,
  Component2
}

// component-1.js

/**
 * The Component1 class
 * @memberof MyLib <- why is this necessary when I'm clearly exporting it in index.js
 */
class Component1 {...}
export default Component1

// component-2.js

/**
 * Component2
 * @function MyLib#Component2 <- why???
 * @param {string} arg - the argument for the function.
 * @returns {Object}
 */
function Component2 (arg) {
  return {
   /**
    * @function MyLib#Component2#someFn <- this basically never works correctly.
    */
    someFn: function () {...},
    /**
     * @function MyLib#Componet2#someOtherFn
     */
   someOtherFn: function () {...}
  }
}
export default Component2

[onury]

:) Unfortunately that's how JSDoc works.

If you don't want to use @memberof or @name to force organize; maybe you should use @namespace tag.

class Component1 { }
function Component2() { }

/**
 * MyLib namespace...
 * @namespace
 */
const MyLib = {
    /**
     * Component1
     */
    Component1,
    /**
     * Component2
     */
    Component2
};

export default MyLib;

[aaronmallen]

yeah its just a small nag I have... I actually really hate the namespace feature as it's not overly apparent what a "namespace" is.

[onury]

Released with Docma v3.0.0.