Remove peer dependency of backend on ecschema-metadata
Move IModelSchemaLoader to ecshema-metadata package where it belongs. It is marked @alpha, so this isn't a breaking change.
@ColinKerr we discussed making backend an optional dependency of ecschema-metadata, but i don't think that's right.
@ColinKerr we discussed making backend an optional dependency of ecschema-metadata, but i don't think that's right.
@kabentley I think it should be a new package altogether that has the dependency of both if we want to move this out of core-backend. What's the issue with keeping this in core-backend?
@kabentley I think it should be a new package altogether that has the dependency of both if we want to move this out of core-backend. What's the issue with keeping this in core-backend?
There's no need for a new package, since anybody who uses this must already have a dependency on ecschema-metadata. I can't think of a reason for this to be part of backend, but the reason to remove it is the confusion it causes that to build backend you need to build ecschema-metadata and you don't.
If there's a reason to worry about the new peer dependency of ecshcema-metadata on backend, I can't think of it. That is a natural, normal, and expected dependency (backend being lower level and always present anyway). It could be made optional, but I can't think of a use-case for ecschema-metadata where backend isn't required (@ColinKerr tried to come up with one but couldn't).
@ColinKerr , @calebmshafer suggested that ecschama-locaters may be a better package for IModelSchemaLoader. That's fine with me, but it can't be in core-backend. Please review/modify/approve.
@ColinKerr , @calebmshafer suggested that
ecschama-locatersmay be a better package forIModelSchemaLoader. That's fine with me, but it can't be in core-backend. Please review/modify/approve.
Yes we agreed on moving it to ecschema-locaters and making the backend package an optional peer dependency. While not an ideal fit it is much better than ecschema-metadata which runs in both frontend and backend contexts. We will move it asap.
@kabentley can this PR be closed now that #4082 is merged?