Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork 5.8k
feat: GitHub style callouts#2487
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
Uh oh!
There was an error while loading. Please reload this page.
Changes from all commits
f9950e0f9a9869db423b66cf5f3672627edee73d5981c1dd026240d33501b0464f5a92543e35dfea3b1b88e32ff9a27faa3607c8adf10fe94234b9c02a8457File filter
Filter by extension
Conversations
Uh oh!
There was an error while loading. Please reload this page.
Jump to
Uh oh!
There was an error while loading. Please reload this page.
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -47,6 +47,12 @@ | ||
| disabled | ||
| /> | ||
| <!-- Prism Theme --> | ||
| <!-- <link | ||
| rel="stylesheet" | ||
| href="//cdn.jsdelivr.net/npm/prismjs@1.29.0/themes/prism-twilight.min.css" | ||
| /> --> | ||
sy-records marked this conversation as resolved.
Uh oh!There was an error while loading. Please reload this page. | ||
| <!-- Site styles --> | ||
| <style> | ||
| /* Plugin: Carbon Ads */ | ||
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be great to add a
console.warnwhen the respective piece of code runs, so people will know. We could also tell people to use major versions in deprecation messages, to start to get versionless people knowing what will be happening, so they can prepare. Wdyt?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Easy enough. Happy to add it. I may consolidate console deprecation warnings as well so they are easier to track and the output can be standardized.
This one may introduce some false positives simply because of the many different ways Docsify can be loaded, but I think a simple search for a
<script>tag with asrcvalue that matches the following criteria could work:.com,.net,.org, etc.)\\docsify(\.min)?\.js@version/and/version/CDN URLs)This would match the following URLs and trigger the console warning:
The following URLs would be ignored:
FWIW, I may opt to implement this in a separate PR. Replying here for convenience. :)
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As per the experience of I work the compatibility release, it seems too complicated for us to handle too much cases.
If we can ensure that we notify as many people as possible who will be affected, notifying additional people who may not be impacted is acceptable.
So I suppose we could make the
versionDetectorsimply like this:Firstly, We check some common CDN providers (unpack, jsdelivr) import path format with versions.
Then, for other importing cases, we only try to find the
docsify.min.jsand thedocsify.jscontent. No matter what the path folder/5/nor the domain is, cos we don't know how users host docsify on which server, which place, which ip, which domain, which CDN...As long as it retrieves new docsify resources without versioning, it gets caught by theversionDetector.When the site contains either resources name of them (
docsify.min.js/docsify.js), we throw out a warning such as:Conclusion:
If users import the resource online (host site on a domain or a raw IP are both okay ), they would get the warning.
If users deploy docsify internally or locally, they won't get a docsify warning, cos they won't get any docsify update also. version control doesn't matter for them. Once they manually upgrade docsify with
versionDetector, they would get the warning then.Besides, we provide a
versionDetectorconfig to manually suppress the warning and checking, when they don't care about any breaking changes or the resource import place is not a generic resources versioning control path (e.g. https://dontblameme.com/libs/update/20240401/docsify.min.js).or am I too straightforward?