-
Notifications
You must be signed in to change notification settings - Fork 0
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
feature Create Linting Package #44
Conversation
aee9174
to
71676f3
Compare
@@ -31,9 +31,9 @@ export const webStorybookColorScheme = () => { | |||
if (colorScheme !== 'light' && colorScheme !== 'dark') { | |||
return null | |||
} | |||
|
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.
Playing with linting did it, I swear. 😆
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.
A couple of questions but overall looks great.
|
||
## Getting Started | ||
These steps assume you already have `eslint` installed for your project as a devDependency and configured correctly. | ||
1. Add `eslint-plugin-deprecate` as a devDependency to your project (peerDependency of package) |
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.
Is there a way to modify our package.json to include eslint-plugin-deprecate
so consumers don't have to add both packages?
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.
Possibly. Thought I saw something recommending having ESLint plugins as peerDependencies, but was maybe crossing streams. I can see if it works including as a dependency.
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.
Appears to work, changes are here/reflected in the 0.2.0-alpha.0 and I just committed them the app-side review (which will need to be bumped one more time after this is merged and published as 0.3.0).
packages/linting/package.json
Outdated
@@ -0,0 +1,34 @@ | |||
{ | |||
"name": "@department-of-veterans-affairs/eslint-config-mobile", | |||
"version": "0.0.1-alpha.0", |
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.
You mentioned bumping this to 0.1.0 once complete, but should we consider keeping this version in line with the corresponding components
packages that contain the same components? I've seen some typescript packages do this.
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.
That makes sense to me with the acknowledgment it'll hop around somewhat randomly to chase components which'll have plenty of updates that do not require updating the linting.
That said, the existing publish workflow can't handle hopping to whatever version matches without us manually seeding it in a way that would align (e.g. committing on the branch up to 0.2.0 to ensure it goes to 0.3.0 alongside Button release).
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.
Bumped to 0.2.0 testing above so it'll be 0.3.0 when published in main in alignment with the addition of Button to the components package.
Ticket 6988
App PR
Description of Change
@department-of-veterans-affairs/eslint-config-mobile
, a little different than other packages to follow ESLint naming guidanceTesting Packages
0.0.1-alpha.0
0.2.0-alpha.0
Testing
Tested it worked as expected within VA Mobile repo w/ alpha build. It yields deprecation warnings for VAButton (and for
semi
colons used for testing behavior which has been removed for v0.1.0 to be published with this PR).PR Checklist
Code reviewer validation:
changelog
label applied if it's to be included in the changelogPublish
If changes warrant a new version per the versioning guidelines and the PR is approved and ready to merge:
main
into branchmain