-
Notifications
You must be signed in to change notification settings - Fork 67
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
Initialise repo #1
Conversation
Can we add a Conventional Commit check? |
module.exports = { | ||
root: true, | ||
env: { | ||
browser: true, |
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.
It's likely we'll need to use overrides
to have different rules for Node.js vs browser packages (e.g. https://github.com/facebook/create-react-app/tree/master/packages/eslint-config-react-app for the latter) in the (very near) future but this should be okay for now.
ecmaFeatures: { | ||
jsx: true, | ||
}, | ||
ecmaVersion: 2020, |
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.
npx eslint --init
set this to 11, but I switched it to 2020 because it's more standard I think. But I actually wonder if we should lower this to the version that current Node.js LTS (10) supports, i.e. ES2017?
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 setting it to 2020 is fine.
12 is the active LTS anyway. And by October, 14 will be active!
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.
Yes but maintenance LTS is what is supported by the ecosystem typically..
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 have a strong position on this, but am apt to pick whatever is new so we can use the latest APIs.
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.
@jpmorganchase/modular-team thoughts?
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 guess we could use Babel (or rather, will most likely end up using Babel anyway) so it doesn't matter
PRs welcome 😛 |
es6: true, | ||
node: true, | ||
}, | ||
extends: [ |
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.
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.
Add it if it is good and catches semantic errors?
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 want to get too carried away in the first PR, these are more just TODOs for future.
This is a possibility. But it suggests that we are going to generate changelogs from commit messages and if we are going to go that direction I would prefer if we could also consider other ways of generating changelogs that allow you to keep using more standard commit messages, for example See: [0] https://twitter.com/4lpine/status/1256976979145797633 |
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 wrote a few more comments.
No description provided.