Skip to content
This repository was archived by the owner on Jan 19, 2019. It is now read-only.

Breaking: Support TypeScript 2.8 (fixes #453) #454

Merged
merged 1 commit into from
Apr 17, 2018
Merged

Breaking: Support TypeScript 2.8 (fixes #453) #454

merged 1 commit into from
Apr 17, 2018

Conversation

JamesHenry
Copy link
Member

@JamesHenry JamesHenry commented Mar 27, 2018

No changes were required to support the existing tests.

We should look to add coverage for new features introduced in 2.8 before this gets merged and check we are aligned with Babylon.

As per our existing conventions, this change is marked as Breaking despite the lack of breaking code changes. This is to be explicit to users that the change is significant within their setup. Also this branch is now protected as usual, so upstream master changes (if any) will need to be merged into this branch.

@nevir
Copy link

nevir commented Mar 29, 2018

TSMinusToken and TSPlusToken are probably the main things this'll run into; though ts-eslint-parser doesn't complain about them, currently (v14.0.0). References:

@lednhatkhanh
Copy link

Hope to see this being merged soon.

@iakovmarkov
Copy link

Is there something that is blocking the merge? Can we help somehow? I'd love to see TS 2.8 being supported.

alangpierce added a commit to alangpierce/speedscope that referenced this pull request Apr 14, 2018
* Install prettier, set up the config file, and run it on all ts and tsx files.
* Install eslint and configure it with just eslint-plugin-prettier to check to
  make sure that prettier has been run.
* Add a basic .travis.yml that runs eslint.

There are other style things that might be nice to enforce with ESLint/TSLint,
like using const, import order, etc, but this commit just focuses on prettier,
which gets most of the way there.

One annoying issue for now is that typescript-eslint-parser gives a big warning
message since they haven't updated to officially support TypeScript 2.8 yet. We
aren't even using any ESLint rules that need the parser, but if we don't include
it, ESLint will crash. TS2.8 support is hopefully coming really soon, though:
eslint/typescript-eslint-parser#454

As for the prettier config specifically, see https://prettier.io/docs/en/options.html
for the available options.

Config settings that seem non-controversial:

Semicolons: You don't use semicolons. (I prefer semicolons, but either way is fine.)

Quote style: Looks like you consistently use single quotes outside JSX and double
quotes in JSX, which is the `singleQuote: true` option.

Config settings worth discussion:

Line width: You don't have a specific max. I put 100 since I think it's a good number
for people (like both of us, probably) who find 80 a bit cramped. (At Benchling we use
110.) Prettier has a big red warning box recommending 80, but I still prefer 100ish.

Bracket spacing: This is `{foo}` vs `{ foo }` for imports, exports, object literals,
and destructuring. Looks like you're inconsistent but lean toward spaces. I personally
really dislike bracket spacing (it feels inconsistent with arrays and function calls),
but I'm certainly fine with it and Prettier has it enabled by default, so I kept it
enabled.

Trailing comma style: Options are "no trailing commas", "trailing commas for
everything exception function calls and parameter lists", and "trailing commas
everywhere". TypeScript can handle trailing commas everywhere, so there isn't a
concern with tooling. You're inconsistent, and it looks like you tend to not have
trailing commas, but I think it's probably best to just have them everywhere, so I
enabled them.

JSX Brackets: You're inconsistent about this, I think. I'd prefer to just keep the
default and wrap the `>` to the next line.

Arrow function parens: I only found two cases of arrow functions with one param
(both `c => c.frame === frame`), and both omitted the parens, so I kept the
default of omitting parens. This makes it mildly more annoying to add a typescript
type or additional param, which is a possible reason for always requiring parens.

Everything else is non-configurable, although it's possible some places would be
better with a `// prettier-ignore` comment (but I usually try to avoid those).
@JamesHenry JamesHenry merged commit e572416 into master Apr 17, 2018
@JamesHenry JamesHenry deleted the ts-2.8 branch June 4, 2018 01:49
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants