colbyfayock
commented
3 months ago hey @mislam - 1.2.1 attempted to introduce a new ENV configuration that would allow for both patterns of VITE and PUBLIC to work: https://github.com/cloudinary-community/svelte-cloudinary/pull/82
however, the issue with this, is it inadvertently broke vanilla Svelte installations, and while SvelteKit likely makes up the majority of use, it was a breaking change that shouldn't have been released as a minor update (if at all), hence the decision to revert it: https://github.com/cloudinary-community/svelte-cloudinary/pull/97
we're trying to figure out a solution that would allow for use of different ENV naming patterns to let any Svelte project utilize this library, whether VITE, PUBLIC, or another less frequent pattern, but need to figure out a good way to handle that
thanks for sharing some ideas on how to move forward with that idea, i'll let the maintainer chime in when she has time about what she had in mind as well
enesbala5
ghostdevv
Bug Report
Describe the bug
After upgrading from v1.2.3 to v1.3.1, I noticed the .env variable changed: from
PUBLIC_CLOUDINARY_CLOUD_NAMEto ->VITE_PUBLIC_CLOUDINARY_CLOUD_NAMEThe use of
VITE_is counter-intuitive for SvelteKit project. It makes more sense to do one of the 3 options:Option 1: Revert back to
PUBLIC_CLOUDINARY_CLOUD_NAME, or Option 2: Let the developer decide on naming and have a config/init to manually initialize the component using the custom env variable name. Option 3. Let both naming (with and w/oVITE_) work, if some people prefer to must haveVITE_.Is this a regression?
Did this behaviour used to work in the previous version? Yes, the previous version in which this bug was not present was: v1.2.3
Steps To Reproduce the error
PUBLIC_CLOUDINARY_CLOUD_NAMEExpected behaviour
Like all other SvelteKit .env variable naming convention, the
VITE_prefix should be removed.Your environment