feat: ignore *.{test,spec}.{js,ts} and similar files - #13009
Conversation
6c43108 to
6e0f0eb
Compare
🦋 Changeset detectedLatest commit: da632f3 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
🦋 Changeset detectedLatest commit: 6e0f0eb The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
preview: https://svelte-dev-git-preview-kit-13009-svelte.vercel.app/ this is an automated message |
*.{test,spec}.{js,ts} and similar files
|
I don't think we need extra config for this - which could also be abused to hide files from the router which it should otherwise not (like a backdoor to customize your routing scheme in weird ways). |
|
I don't agree with that. First, because you may have different/multiple extensions, or a combination. It's not rare to see:
Also, I don't believe something shouldn't be added just because there is a chance it can be misused. |
6e0f0eb to
b5d60b8
Compare
a1c4974 to
d4298f8
Compare
Maybe that's a feature? Because that's what this is actually doing — So it could be something like this instead: // svelte.config.js
export default {
kit: {
router: {
ignore: /\.(test|spec|stories)\./
}
}
};I think we'd probably only want to apply it to the Thoughts? Should the regex in that example be the default? |
|
We decided to go with a non-config approach, so closing this in favour of #16715 — thank you! |
…16715) Simpler alternative to #13009. We decided it's probably fine — and presents less risk of forcing breaking changes on us in future — to just hardcode this list. If that turns out to be the wrong decision we can easily add configuration like `router.ignore` as proposed in #13009 (comment), but for now this seems like the easier option. Closes #13008 --- ### Please don't delete this checklist! Before submitting the PR, please make sure you do the following: - [x] It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs - [x] This message body should clearly illustrate what problems it solves. - [x] Ideally, include a test that fails without this PR but passes with it. ### Tests - [x] Run the tests with `pnpm test` and lint the project with `pnpm lint` and `pnpm check` ### Changesets - [x] If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running `pnpm changeset` and following the prompts. Changesets that add features should be `minor` and those that fix bugs should be `patch`. Please prefix changeset messages with `feat:`, `fix:`, or `chore:`. ### Edits - [x] Please ensure that 'Allow edits from maintainers' is checked. PRs without this option may be closed.
Closes #13008, please see issue for more details
Please don't delete this checklist! Before submitting the PR, please make sure you do the following:
Tests
pnpm testand lint the project withpnpm lintandpnpm checkChangesets
pnpm changesetand following the prompts. Changesets that add features should beminorand those that fix bugs should bepatch. Please prefix changeset messages withfeat:,fix:, orchore:.Edits