-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Parse Deprecation.forVersion on compiler side #3868
Conversation
c94fb60
to
51321aa
Compare
A couple of things related to this:
|
In theory yes, but at the same time I prefer more logic to be handled on the compiler side, to reduce duplicated code logic, and potential inconsistency due to errors in different implementations. |
51321aa
to
2231e36
Compare
I have update the PRs to match the CLI behavior. For JS API in embedded-host-node, unfortunately this is only enforced when users write code in TypeScript. When writing in pure JavaScript I can do the following to silence the "slash-div" with a version input, and it indeed silences the warning due to lack of runtime checks: sass.compileString('a {b: (1px / 2);}', {silenceDeprecations: [sass.Version.parse('2.0.0')]}) @jathak If this should have not worked as you have described, implementing this on the compiler side can help host implementations to have better consistency. |
I implemented the deprecations API for my host & fwiw, before looking at the details, did expect the by-version flavour to be implemented on the compiler side. The approach proposed here makes naive sense to me as providing a single implementation of the mapping. Might be useful to hear the reasoning/benefits for the previous proposal where each host individually implements the mapping based on the yaml file? |
The yaml file is to provide host implementors a source to generate static constants for deprecations, so that the end users can auto complete the deprecations based on the static constants (of course, the generation logic is up to each implementor). It does not conflict with the idea of parsing |
Yeah, the more I think about this, it does make sense to support versions for Regarding the behavior in pure JavaScript, that is indeed a bug. Only |
2231e36
to
fbf959a
Compare
This allow the embedded-host-ruby to accept a deprecation version as input, without the need of maintaining the complete deprecation list on the host side.