-
-
Notifications
You must be signed in to change notification settings - Fork 204
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
Use custom parser for gts/gjs #1942
Conversation
2578221
to
a96dc3b
Compare
// override / enable optional rules | ||
'ember/no-replace-test-comments': 'error' | ||
} | ||
}; |
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'd prefer we specify:
overrides: [
{
files: ["**/*.{gjs,gts}"],
parser: 'ember',
}
]
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.
would this also be okay?
{
files: ['**/*.gts'],
parser: 'eslint-plugin-ember/gts-parser',
},
{
files: ['**/*.gjs'],
parser: 'eslint-plugin-ember/gjs-parser',
},
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.
Yeah
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 seems fine, but just wondering, is there a need or benefit to separating the parsers, or can they be specified as one?
overrides: [
{
files: ["**/*.{gjs,gts}"],
parser: 'eslint-plugin-ember/gjs-gts-parser',
}
]
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.
we could.
we would need to detect if the extension is gts or gjs and choose by that, which internal parser should be chosen
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.
Would that be simple? Is there any reason why we shouldn't just auto-detect the extension for the user? If the user doesn't care about distinguishing between these file types, then we can avoid exposing that complexity to the user, and just handle it internally, right?
2bb7972
to
71d19ff
Compare
@bmish @NullVoxPopuli
Though i remember the idea was to get rid of ember-template-imports here. |
4eff4a0
to
e8c8be6
Compare
msgs[0].ruleId === null && | ||
msgs[0].message.startsWith('Parsing error: ') | ||
) { | ||
if (!parsedFiles.has(fileName)) { |
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 is how we check if the file went through our parser or not.
I only notify the user if a parsing error happened. We could also always notify the user if its not correctly setup.
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 this is great! is there a way to check if a gjs / gts file was passed to this though? right now I have a concern about non-gjs and non-gts files hitting this message, would be over-aggressive
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.
Well, the preprocessor is only setup for those files. So it only enters if for gjs/gts
}`, | ||
errors: [ | ||
{ | ||
message: 'Parsing error: Unexpected token (2:40)', |
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.
here the error when setup is correct, but some other syntax error
e8c8be6
to
e50fde7
Compare
'Parsing error: Unexpected token. A constructor, method, accessor, or property was expected.\n' + | ||
'To lint Gjs/Gts files please follow the setup guide at https://github.com/ember-cli/eslint-plugin-ember#gtsgjs-eslint-setup', |
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.
here is the error when not setting it up correctly
@bmish @NullVoxPopuli |
e50fde7
to
2260f0c
Compare
In your PR description, your eslint config uses the root namespace for configuring ember stuff -- I think we need to move the community more towards an overrides-only approach, which I'd been trying to get folks to care about for some time. For example: // .eslintrc.js
module.exports = {
overrides: [
{
files: ['**/*.gts'],
parser: 'eslint-plugin-ember/gts-parser',
plugins: ['ember'],
extends: [
'eslint:recommended',
'plugin:ember/recommended', // or other configuration
],
},
{
files: ['**/*.gjs'],
parser: 'eslint-plugin-ember/gjs-parser',
plugins: ['ember'],
extends: [
'eslint:recommended',
'plugin:ember/recommended', // or other configuration
],
},
{
files: ['tests/**/*.{gjs,gts}'],
rules: {
// override / enable optional rules
'ember/no-replace-test-comments': 'error'
}
}
],
}; Reason being that it's way easier to manage long term, as it flattens the amount of cascading you force yourself in to, and you can more easily opt out of plugins, because they never existed for a particular folder in the first place. This aligns nicely with the direction ESLint9 is going in as the current config format will be dropped. 🙃 this is all tangential to the PR tho lol |
lib/parsers/gjs-parser.js
Outdated
} | ||
|
||
/** | ||
* simple tokenizer for templates, just splits it up into words and punctuators |
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 totally be in a followup PR, but does it makes sense for this to have its own unit tests?
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.
Maybe, though once the indent rule is added, it will also be tested indirectly :)
@@ -472,6 +564,40 @@ describe('lint errors on the exact line as the <template> tag', () => { | |||
}); | |||
}); | |||
|
|||
describe('supports eslint directives inside templates', () => { |
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.
oooooo
const code = ` | ||
<template> | ||
<div> | ||
<!--eslint-disable-next-line--> |
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.
wouldn't this get shipped to users tho? 😅
(non-blocker, just a goofiness)
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.
Nice work -- thanks for iterating on this, and greatest apologies we had to revert the first time around <3
That would also be good, by using extends in overrides it would not also not be strictly necessary to specify the parser. As that is set in the recommended config. {
files: ['**/*.{gjs,gts}'],
plugins: ['ember'],
extends: [
'eslint:recommended',
'plugin:ember/recommended', // and other
} Or a base config? |
follow-up prs i would like to include in the next major: |
@bmish any news for this? |
eti v4 is more a signal that content-tag should be good to go in the linting prs. |
content tag still doesn't emit a format that's usable for linting |
It has a second api specifically for linting. Check my glint pr where the ranges are used |
I will have a look, but here ranges are not enough. |
mmm, so glint uses that to do it's own transform? |
5981ad7
to
767ba8d
Compare
@bmish @NullVoxPopuli I updated this to use the latest content-tag |
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 great!
@patricklx this one needs rebase real quick |
aca80ed
to
8b53ff0
Compare
4d93fa9
to
df57176
Compare
df57176
to
9dbfa05
Compare
@NullVoxPopuli this now uses latest glimmer/syntax |
bonus:
disavdvantage:
needs specific configuration to enable the parser, as setting it globally will overwrite it.
like https://github.com/vuejs/vue-eslint-parser does.
Breaking change:
e.g.
fixes #1770
fixes #1894
fixes #1747
fixes #1683
fixes #1659
also fixes ember-tooling/prettier-plugin-ember-template-tag#81
fixes ember-tooling/prettier-plugin-ember-template-tag#84
closes #1667
closes #1957