This is a parallel feature to the metadata file for lists (.listname.yaml files) used for storing the list counter (and any future list metadata).
For objects, this should be a ._this.yaml file that has the same lifecycle as the metadata file for lists, which I believe is only created when the metadata is non-empty (please confirm). This would mean the file may or may not be present, but when it is, it must be utilized by all yds functions.
The first metadata property for the object metadata file will be a list of simple strings stored inline named ignoredPaths. This property will identify local paths (file names and directory names) within the on-disk representation of the object in question that are to be completely ignored by all yds functions within this object. Should a function attempt to access any path listed in ignoredPaths (for example because the user hand editing a file or passed an ignored element name to a function) then the function should report an error indicating an invalid element name.
The ignoredPaths feature will enable yds managed directories to have files/directories within them that are managed by other tools. This is especially helpful when we are managing projects utilizing yds with companion tools such as npm.
Example:
Let's consider a case where we are using npm inside a yds object. We may want to ignore the node_modules directory, the package.json file, and the package-lock.json file as these are all managed by npm. In this case, the ._this.yaml file would look something like this.
ignoredPaths:
- node_modules
- package.json
- package-json.lock
Then if the user attempted to load("package_json") the load function would need to report an error of "invalid element [package_json], package.json in the ignored paths list".
And if the user modified the object in memory to include an object property named node_modules then called store (assuming the directory contained the ._this.yaml file and was otherwise empty), the store function would need to report an error of "invalid element to store [node_modules], node_modules in the ignored paths list".
We will need to specify all of these error cases and update the tests to detect them.
This is a parallel feature to the metadata file for lists (
.listname.yamlfiles) used for storing the list counter (and any future list metadata).For objects, this should be a
._this.yamlfile that has the same lifecycle as the metadata file for lists, which I believe is only created when the metadata is non-empty (please confirm). This would mean the file may or may not be present, but when it is, it must be utilized by all yds functions.The first metadata property for the object metadata file will be a list of simple strings stored inline named
ignoredPaths. This property will identify local paths (file names and directory names) within the on-disk representation of the object in question that are to be completely ignored by all yds functions within this object. Should a function attempt to access any path listed inignoredPaths(for example because the user hand editing a file or passed an ignored element name to a function) then the function should report an error indicating an invalid element name.The
ignoredPathsfeature will enable yds managed directories to have files/directories within them that are managed by other tools. This is especially helpful when we are managing projects utilizing yds with companion tools such as npm.Example:
Let's consider a case where we are using npm inside a yds object. We may want to ignore the
node_modulesdirectory, thepackage.jsonfile, and thepackage-lock.jsonfile as these are all managed by npm. In this case, the._this.yamlfile would look something like this.Then if the user attempted to
load("package_json")the load function would need to report an error of "invalid element [package_json], package.json in the ignored paths list".And if the user modified the object in memory to include an object property named
node_modulesthen called store (assuming the directory contained the._this.yamlfile and was otherwise empty), the store function would need to report an error of "invalid element to store [node_modules], node_modules in the ignored paths list".We will need to specify all of these error cases and update the tests to detect them.