Open daKmoR opened 2 years ago
Those were not documented in readme. Sticking with some file structure would not let the project to evolve.
Id recommend to refactor svgo usage as plugin instead of hacking internals. As fast fix you can use /lib/parser module which is also private so do not expect it to work forever.
Those were not documented in readme. Sticking with some file structure would not let the project to evolve.
fully agree with that 👍. that's why I would highly recommend an export map as it will "enforce" this. You can freely restructure without breaking any public API. (e.g. the internal API will not be accessible at all - if a user require/import it node will throw an error)
Id recommend to refactor svgo usage as plugin instead of hacking internals.
I'm just a user of svg2vectordrawable but I will raise this suggestion there as that sounds like a good path forward 🤗
Exports field may break some usages. Wouldnt like to introduce it before next major.
Exports field may break some usages. Wouldnt like to introduce it before next major.
makes sense 👍
Btw this project need to get rid from coa which was compromised recently.
Describe the bug Since 2.7.0 the file
svgo/lib/svgo/svg2js
no longer exists... it is used in https://github.com/Ashung/svg2vectordrawableIs there a "public" API with the capabilities of svg2js?
To Reproduce Steps to reproduce the behavior:
mkdir test; cd test
npm i svg2vectordrawable svgo
$ npx s2v -h
Expected behavior
s2v
to runDesktop (please complete the following information):
Additional context
I search through some issues and it seems svg2js is considered a private API? if so how about releasing a new major version with an "export" map then those apis will become actually private (e.g. users will no longer be able to import anything that is NOT in the export map)
https://nodejs.org/api/packages.html#exports