Make metadata file locations clearer

[nilliams]

It would be good if the Readme made it clearer that the metadata files in question need to be loaded in the metalsmith 'tree', e.g. in your src directory if using default options. Took me a while to figure this out - had to look at the source.

As you invoke metalsmith on __dirname I think you could reasonably expect it to find metadata files relative to there (I did).

You might also expect absolute file paths to work (perhaps if invoking from some higher-level tool, gulp etc) and of course they don't for the same reason. I think this is reasonable, but should probably be noted as well.

Thanks!

[gearsdigital]

👍

[davidknezic]

👍

[igregson]

👍

[Arkkimaagi]

👍 I too came looking for this after failing miserably.

[thiagodemellobueno]

Which also begs the question... is that desireable?
The very reason I installed this plugin, was so that I could share variables between metalsmith and gulp.
So having it in my root, or in /metadata/ or /variables/ would be desireable.

[kaishin]

Agreed, I spent quite some time debugging this.

[nilliams]

Can I propose the following behaviour:

1. paths of form path/to/thing.json assumed to be from the metalsmith tree/stream (current functionality)
2. paths of form ./path/to/thing.json assumed to be relative from __dirname
3. paths of form /path/to/thing.json (or windows equiv.) assumed to be absolute paths

Hopefully intuitive/in-alignment with how require statements work etc. ?

As it's such a tiny script I'd love to have a crack at a PR as soon as I get a sec, just putting this out there for anyone else coming across this or for thoughts from you guys who have already been burned?

EDIT: Only bummer with this is this is actually backwards incompat. with the example in the current README, which uses ./paths/like/this to mean #1 above, so it would break existing code.

Perhaps just passing an option: absolute: true, relative: true or pathStyle: 'relative' | 'absolute' is safer/more explicit, if a little uglier.

[rebolyte]

Just hit this problem like everybody else. Could we get this issue addressed (with the readme also noting that the leading ./ shouldn't be in the filepath)?

[patdavid]

I'm hitting this same problem, but at the moment the behavior between WIN/OSX is not consistent(?!). Works on OSX, does not appear to work on win...

[jmjf]

@nilliams
What if all paths were relative to the Metalsmith tree, but remove the restriction that all paths must be in the Metalsmith tree. Then old code would still work with path/to/thing.json or ./path/to/thing.json. Case 2 becomes ../path/to/thing.json, which is reasonable. Case 3 remains as is and works.

[fizzydigital]

this needs to be resolve ASAP!

[ArrayKnight]

Yea, the inconsistency between OSs is really holding things back for my team.

[rgoliveira]

Only way I got it to work (on Windows) was to place my json files inside de src folder...

Tried absolute, relative with and without the ./ at the beginning... Nothing seems to work.

Debugged the current working directory in the plugin, and it's pointing to the root of the project, so I have no idea why this won't work.

[jemjam]

So I'm not totally sure if this solves the issues with regards to the Windows inconsistency, but I made a fork of the plugin to at least deal with loading data from files outside of the src folder.

https://github.com/JemBijoux/metalsmith-metadata/tree/ext-data-sources
(Note you can npm install jembijoux/metalsmith-metadata#ext-data-sources to try it yourself.)

1. I made sure to use path.normalize() on the file path first. Another PR (Normalize file path #11) seemed to include this for files within subdirectories. Seemed like a good first step.
2. I changed up the format of the plugin settings to include a config option. The datafiles are now under "files": {}, and then you set "config: { isExternalSrc: true } to read in external data. See my updated readme for an example.

Once the files are sourced they're included on the metadata just like before, so all this really does is provide a means of loading other data files outside those included in the metalsmith source (src).

I can't test on Windows myself, but I wonder if making use of the option could help folks having difficulty between OS's (as it makes use of a more familiar node path style)? Any feedback is welcome, let me know if this is helpful to anyone.

[renomateo]

👍 👍 👍

[dkolba]

👍

[luisalima]

👍 👍 👍

[howarddierking]

This has been open for a while. Does this change request feel appropriate to the project? If so, happy to provide a PR..

[gishnanigans]

I still can't make the path work. After inspecting the code and trying every possible option (except clearly the one that works). I'm about to rewrite this functionality from scratch just so I can make it work. But would rather it work out of the box.

I did a path.resolve(file) directly in this modules index.js and it points straight to my file. Likewise, my file is in the metalsmith files hash and using that key also did not work.

As far as I'm concerned this module is broken.

Okay, I got it to work, doing "exactly" what I had already done, that is using the files hash value as the path-key. Still, this needs to be documented and a decent example provided to illustrate how to map the paths.

[iamkahvi]

Had similar issue on Windows. Kept getting file not found errors that would prevent the html files from building. In the end, I just moved the metadata files from src/metadata to src and changed the filepaths for the plugin and that solved it.
This was specific to windows though, the build works on OSX and linux without the path changes.

[wernerglinka]

Version 1.0.0 assumes that all metadata files/directories are located in the Metalsmith root directory. Please open a new issue with any new problems.