-
-
Notifications
You must be signed in to change notification settings - Fork 8.7k
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
feat(sitemap): add ignorePatterns option #6979
Conversation
Hi @ApsarasX! Thank you for your pull request and welcome to our community. Action RequiredIn order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you. ProcessIn order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA. Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with If you have received this in error or have any questions, please contact us at [email protected]. Thanks! |
✅ [V2]Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site settings. |
⚡️ Lighthouse report for the changes in this PR:
Lighthouse ran on https://deploy-preview-6979--docusaurus-2.netlify.app/ |
Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks! |
@@ -24,6 +25,9 @@ const PluginOptionSchema = Joi.object({ | |||
.valid(...Object.values(EnumChangefreq)) | |||
.default(DEFAULT_OPTIONS.changefreq), | |||
priority: Joi.number().min(0).max(1).default(DEFAULT_OPTIONS.priority), | |||
ignorePatterns: Joi.array() | |||
.items(Joi.object().instance(RegExp)) |
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.
Can we allow strings as well, which will be glob patterns like /tags/**
? We have a utils.createMatcher
for that.
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.
this runs in Node side so why not expose a callback as well (and thus rename to simply "ignore"?)
a callback is always the most flexible option
now I'm not against providing support for RegExp/globs too but all this can be implemented in userland with a callback and this is a quite niche feature 🤷♂️
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 don't really like callback-based APIs unless we can't implement a good solution otherwise—Webpack loaders don't use callbacks everywhere only because they can. I do prefer serializable APIs if they provide the right level of abstraction. While ignorePatterns: ["/tags/**"]
is probably as useful as ignore: (path) => path.startsWith("/tags/")
, the former is more well-understood by everyone and more approachable for those not well-versed with JS.
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 don't know, it's also more ambiguous because some edge cases might depend on the underlying glob library etc... A callback always behaves explicitly, other apis are just shortcuts.
Not saying that we shouldn't provide shortcuts, but this use-case seems niche enough that a lower-level but more flexible API might be enough
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 agree that glob patterns are better than regular expressions, and I've used utils.createMatcher
instead of regular matching.
In addition, I don't quite agree to use the callback based API, because it will make docusaurus.config.js
looks disorganized. And not all docusaurus users are professional programmers.
packages/docusaurus-plugin-sitemap/src/__tests__/options.test.ts
Outdated
Show resolved
Hide resolved
|
||
const sitemapStream = new SitemapStream({hostname}); | ||
|
||
routesPaths | ||
.filter((route) => !route.endsWith('404.html')) | ||
.filter( |
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.
should we apply trailingSlash before the filtering? I don't know what is best in this case 🤷♂️
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.
404s should not be applied trailing slash anyways, I think this is fine. The odds that someone gets tricked by this seems low to me, and they can always check their glob.
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.
Added some comments
That looks rather nice, thanks! I will do a few refactors, hold back while I commit 😄 |
In addition, I found a problem about |
Ah yes, I think matching none seems like better semantics. Will fix it in this commit |
Is there any problem with this PR? |
Thanks 👍 Not 100% convinced that |
Motivation
When I generate a sitemap, I want to ignore some paths, such as the path starting with
/tags
, so I add an option namedignorePatterns
toplugin-sitemap
, which accepts an array of regular expressions and allows users to ignore some paths that do not need to appear in the sitemap.Have you read the Contributing Guidelines on pull requests?
Yes.
Test Plan
I've added several test cases in the following files.
packages/docusaurus-plugin-sitemap/src/__tests__/createSitemap.test.ts
packages/docusaurus-plugin-sitemap/src/__tests__/options.test.ts
.Related PRs
No other PRs related to this request as far as I could find.