-
-
Notifications
You must be signed in to change notification settings - Fork 4.7k
[feat] Add errorMode option to compile to allow continuing on errors (and mark them as warnings) #6194
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] Add errorMode option to compile to allow continuing on errors (and mark them as warnings) #6194
Conversation
- allow compiler to pass error as warnings - enforce stops after errors during compilation - should review Element.ts:302 - add a test case for errorMode - adding documentation
|
|
||
| component.slot_outlets.add(name); | ||
| // this code was unreachable. Still needed? | ||
| // component.slot_outlets.add(name); |
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 indicated, this code was unreachable before this PR.
I think we could safely remove it since:
- It is unreachable 😁
- It does
set.addin aset.has(what ?)
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.
In most cases you do return component.error(.., I'd keep it consistent and do that in the other places, too.
|
I couldn't because TypeScript was not happy when I do this in a If you look, all |
dummdidumm
left a comment
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.
Looks good to me 👍 The same mode could be of use later on in a different PR when being more forgiving while parsing (not compiling, which is this PR), helping language tools.
I'm not sure what the unreachable code was trying to do, that might be something for @Conduitry / @tanhauhau to look at, maybe you accidentally discovered a bug.
|
Thank you for merging this PR, I will restart my work on the |
|
This has been released in 3.39.0. |
Description
This PR adds a new option
errorModetoCompileOptionsto allow continuing the compilation process when errors occured.When set to
warn, this new option will indicate to Svelte that it should log errors as warnings and continue compilation.This allows (notably) preprocessors to compile the markup to detect
varsin markup before preprocessing (in this case:scriptandstyletags are stripped so it can produce a lot of errors).To avoid breaking change, the old behavior is still the default option (
throw).This PR is part of a work on the
svelte-preprocessside to improve the preprocessing of TypeScript files:sveltejs/svelte-preprocess#318
Some features were implemented in the following PRs:
Details
This PR does the following:
returnafter allcomponent.error()calls to avoid breaking the compilationReview
During the implementation, I detected an unreachable code.
To allow the review, I only commented this line: https://github.com/sveltejs/svelte/pull/6194/files#r612613005
I think that it could be safely removed for 2 reasons:
Set.addin aSet.hasWhat do you think?
Before submitting the PR, please make sure you do the following
Tests
npm testand lint the project withnpm run lintThanks