Add 2019-02-28 meeting notes (closes #120) (#121)

notes/2019/2019-02-28.md

@@ -0,0 +1,115 @@
+# 2019-February-14 ESLint TSC Meeting Notes
+
+## Transcript
+
+https://gitter.im/eslint/tsc-meetings/archives/2019/02/28
+
+## Attending
+
+* Teddy Katz (@not-an-aardvark) - TSC
+* Nicholas Zakas (@nzakas) - TSC
+* Brandon Mills (@btmills) - TSC
+* Kevin Partington (@platinumazure) - TSC
+
+Additionally, the following individuals are not in attendance but support consensus:
+
+* Gyandeep Singh (@gyandeeps) - TSC
+* Kai Cataldo (@kaicataldo) - TSC
+
+## Topics
+
+### [Fix: no-var fixed to incorrect code (fixes #11441)](https://github.com/eslint/eslint/pull/11443)
+
+* **Summary**: When using the TypeScript parser, the fixer for `one-var` can replace `declare var foo: number;` with `let var foo: number;` because it assumes the first token is the `var` keyword without actually verifying that.
+* **Question**: Though everything works okay using the default parser, should we still accept the change as a bugfix to improve compatibility with custom parsers?
+* :+1: from @nzakas, @btmills, @not-an-aardvark, @platinumazure
+
+### [v6.0.0](https://github.com/eslint/eslint/projects/5)
+
+#### Drop Node.js 6 support
+
+* Release does not necessarily need to come after Node.js 6 EOL in April, though it likely will.
+* :+1: from @nzakas, @btmills, @not-an-aardvark, @platinumazure
+
+**Resolution**: We will drop support for Node.js 6. @not-an-aardvark will create an issue to discuss minimum versions of the supported major releases.
+
+#### [eslint-recommended changes in eslint v6.0.0](https://github.com/eslint/eslint/issues/10768)
+
+* @nzakas proposes marking the issue as accepted and discussing the exact rule changes on the issue.
+* :+1: from @nzakas, @btmills, @not-an-aardvark, @platinumazure
+
+**Resolution**: We will accept breaking changes to `eslint:recommended` with specifics to be determined.
+
+#### [Throw an error for invalid `globals` values](https://github.com/eslint/eslint/pull/11338#discussion_r252497158)
+
+* :+1: from @btmills, @platinumazure, @nzakas, @not-an-aardvark
+
+**Resolution**: This is accepted as a breaking change in v6.0.0.
+
+#### [do not ignore files started with `.` by default](https://github.com/eslint/eslint/issues/10341)
+
+* Linting directories like `.git` by default would be confusing.
+* Users can still manually enable linting dot-prefixed files and directories.
+* Coming up with a list of one-size-fits-all default exceptions would be difficult.
+* @mysticatea and @kaicataldo left :+1: on the issue
+* :-1: from @platinumazure
+* @nzakas suggests tabling for v6 and discussing later. :+1: from @platinumazure, @btmills, @not-an-aardvark
+
+**Resolution**: This proposal is tabled for discussion after 6.0.0.
+
+#### [Stricter `no-undef` default](https://github.com/eslint/eslint/issues/10203)
+
+* Currently, `typeof foo` checks when `foo` is not defined will not be caught unless the user has enabled the `typeof` option.
+* This proposes enabling the `typeof` option by default so that `typeof foo` would cause a warning unless the user disables the option.
+* @platinumazure is against :-1: because `typeof foo` is permitted by the language spec. `typeof` checks do not throw a `ReferenceError` at runtime. Further, since users can already opt into the check, this would be a breaking change without significant value.
+* @not-an-aardvark is mildly in favor :+1: because this check could be helpful during refactoring, and users often follow the `typeof` check with a usage, so they'd already have to add a disable comment.
+* @platinumazure would prefer that users add the potentially-defined variable to `globals`.
+* @btmills finds the refactoring argument compelling, but feels this is getting into the domain of a typechecker, and the edge cases don't justify this as a breaking change.
+* @nzakas proposes tabling for reconsideration in 7.0.0. No objections from @btmills, @platinumazure, @not-an-aardvark
+
+**Resolution**: This proposal is tabled for reconsideration in 7.0.0.
+
+#### [Proposal: change no-redeclare default behavior](https://github.com/eslint/eslint/issues/11405)
+
+* This would enable `no-redeclare`'s `builtinGlobals` option by default so that variable declarations that shadow environment globals would cause a warning.
+* :+1: from @nzakas, @not-an-aardvark, @btmills, @platinumazure
+
+**Resolution**: This is accepted as a breaking change in v6.0.0.
+
+#### [Proposal: no-redeclare reports /*globals foo*/ comments if it's redeclaration](https://github.com/eslint/eslint/issues/11370)
+
+* This would cause a warning for `/* globals ... */` comments that redeclare already existing variables.
+* There are some edge cases that should be outlined, so an RFC is necessary.
+* :+1: pending an RFC from @btmills, @platinumazure, @nzakas, @not-an-aardvark
+
+**Resolution**: This proposal is accepted as a breaking change in v6.0.0 pending an RFC.
+
+#### [Interpret user-provided regexes in rule options with the `u` flag](https://github.com/eslint/eslint/issues/11423)
+
+* :+1: from @platinumazure, @not-an-aardvark, @btmills, @nzakas
+
+**Resolution**: This proposal is accepted as a breaking change in v6.0.0.
+
+#### [Enable ES2015 parsing/globals by default](https://github.com/eslint/eslint/issues/11419)
+
+* Should we set `parserOptions: { ecmaVersion: 2017 }` and enable the `Atomics` and `SharedArrayBuffer` globals by default?
+* How would disabling work? Would setting the `env` to false also disable globals?
+* Right now `Atomics` and `SharedArrayBuffer` are not part of any environment. We could add an `es2017` env that enables `parserOptions: { ecmaVersion: 2017 }` and also `Atomics` and `SharedArrayBuffer`, and enable that env by default.
+* Do these defaults apply when there are no other settings, or do we start with the defaults and require users to remove them if they want to target an earlier version?
+* There are 3 sub-proposals:
+    1. Enable `env: { es6: true }` when that env is not configured otherwise
+    1. Enable `parserOptions: { ecmaVersion: 2017 }`, `env: { es6: true }`, and the two ES2017 globals by default, and allow each of them to be overridden independently
+    1. Create a new `es2017` env and enable it by default when not configured otherwise
+* There are enough edge cases here that an RFC would help.
+* @nzakas, @btmills, and @platinumazure are uncomfortable pre-approving without seeing the RFC. Does that mean it this gets pushed to 7.0.0?
+* @nzakas believes we decided in the previous meeting to lock down 6.0.0 today.
+* A two-step process with time for clarification and refinement in between could help cases like this that might not need to be pushed to a future major release if some questions can be answered.
+* Previous meeting notes show we decided to discuss but not lock down the 6.0.0 roadmap today, so we can extend discussion into the next meeting to give time for RFCs to answer questions. 6.0.0 will be locked down by the end of the next meeting.
+
+**Resolution**: @not-an-aardvark will create an RFC with more details on this proposal. We will consider it in the next meeting, after which 6.0.0 will be locked down.
+
+### [Scheduled release for March 1st, 2019](https://github.com/eslint/eslint/issues/11412)
+
+* This will include a bugfix release of `eslint-scope`.
+
+**Resolution**: @not-an-aardvark and @platinumazure will do the release.