Repository navigation
dumping is formating custom type wrong #576
Description
const yaml = require("js-yaml")
class Test {
constructor(id) {
this.id = id
}
id
get Id() {
return this.id
}
async fetchData() {
console.log("get async data")
}
}
var customtagYamlType = new yaml.Type("!mapInfo", {
kind: "scalar",
resolve: () => true,
construct: (id) => new Test(id),
instanceOf: Test,
represent: (customTag) => customTag.id,
})
const obj = {
name: 'some',
data:{
content:[
{
value: new Test("1")
}
]
}
}
const schema = yaml.Schema.create([customtagYamlType])
const result = yaml.dump(obj, { schema })
console.log(result)
/* the output is
data:
content:
- value: !<!mapInfo> '1'
-----------------------------------------
i am expecting like in the documentation
data:
content:
- value: !mapInfo '1'
node version v12.14.1
*/
Activity
rlidwka commentedon Sep 15, 2020
Those string representations are equivalent:
!<!mapInfo>is a global version of the application-local tag!mapInfo, both variants are acceptable I believe.Does it cause any issues (e.g. interoperability with other parsers)?
coderwaschbaer commentedon Sep 18, 2020
Yes they are equivalent but the same library throw an error when convert from
!mapInfoto!<!mapInfo>and i try to convert again to json. My example to get in context is that i am making an app which convert Yaml to Json shows a UI where you can edit the content and after that will convert the json again to YAML. I have to usestring.replace('!<!mapInfo>', '!mapInfo' )after dumping. It is working fine but if the object is to long with a lot of custom tags i will compromise the perfromance of the appdanmactough commentedon Oct 4, 2020
+1 I am also working on a library where I want to be able to load yaml with custom tags, process/transform the data, and then dump the transformed data as yaml while preserving the original -- I want to be able to perform a diff and don't want every custom tag rewritten.
If we had an option available when creating a Type (for example, a boolean flag --
dumpTagsWithGlobalWrapper), it seems like here, we could propagate that option to thestatewith something likestate.dumpTagsWithGlobalWrapper = !!type.dumpTagsWithGlobalWrapper. Then where we currently add that wrapper here, we could conditionally add the wrapper or not.Would you accept a PR for this?
rlidwka commentedon Dec 25, 2020
Fixed in a0d0caa (currently in
devbranch).Now tag behavior aligns with
pyyaml, where custom tags are dumped as!tag, and there is no way to dump those as!<!tag>. Please tell me if there's any use-case for the old behavior.Duplicate of:
#364
#187