Version 1.0.0

[dcousens]

Any reason to hold off on this?
The package appears to be stable.

---

Hijacking OP for visibility (@bradzacher)

We're actively working on it (and almost there!)
You can track the progress here: https://github.com/bradzacher/eslint-plugin-typescript/milestone/1

[todorone]

@JamesHenry Any chance You could publish new version to npm please?

[bradzacher]

per the definition of semver, publishing 1.0.0 implies that we are releasing a breaking change.
I think we'll save that for when we actually have a breaking change.

I'll be looking at pushing a new version within the next few days.

[todorone]

@bradzacher Amazing, thanks.

[corbinu]

@bradzacher not to be rude but technically before 1.0.0 the rules of semver are actually looser than after. Usually it symbolizes "stable for production". The https://semver.org/ website does have an FAQ with some details. This lib is for sure being used in production so it is probably close to 1.0.0.

However I expect there are a lot of changes coming so maybe plan a few more releases then 1.0.0.

So glad your taking this over! I am quite slammed as I work in eCommerce but after Black Friday should have sometime to do more than just play the peanut gallery.

[macklinu]

Would we want to complete the remaining rules in #5 as part of a 1.0.0 release?

[bradzacher]

@corbinu I didn't actually know that, thanks!

TBH I'm not 100% comfortable releasing as a 1.0.0 "stable" because of the number of issues that keep popping up with no-unused-vars.
Though we're probably just going to have to bite the bullet on that one though considering there are so many edge cases (and we've got the majority of them, I think...).

@macklinu we probably need to define the goals of the plugin.
Is the goal to be a "feature-complete tslint alternative"?
If yes, then we should probably finish #5 before a 1.0.0 release.
If no, then we're in a decent place for a 1.0.0 release (based on the proper definition of 1.0.0 😃)

Regardless, it's probably a good idea to assess the severity/impact of the current known bugs first so we can decide if we are "production stable".

I went through last night and tagged all the current issues appropriately.
I'll spend some time on the weekend properly investigating and post back here.

If you anyone wants to help; feel free to assign yourself to ones you're investigating so we don't double dip on effort.

[JamesHenry]

@bradzacher The single most important thing before 1.0.0 can be considered IMO is bringing things up to date with advancements in the parser. It is very out of date right now.

This PR in particular has major ramifications for the plugin: eslint/typescript-eslint-parser#540

[bradzacher]

thanks @JamesHenry. I opened #166 last night to track the upgrade.
definitely will have to address that for the 1.0.0.

We might want to add a peer dep (or actual dep) to help keep it tighter and make it easier for users to know what version to use.

I should create a milestone so we can track everything we want for a 1.0.0...

[JamesHenry]

Awesome

…

On Fri, 16 Nov 2018 at 20:03, Brad Zacher ***@***.***> wrote: thanks @JamesHenry <https://github.com/JamesHenry>. I opened #166 <bradzacher/eslint-plugin-typescript#166> last night to track the upgrade. definitely will have to address that for the 1.0.0. We might want to add a peer dep (or actual dep) to help keep it tighter and make it easier for users to know what version to use. I should create a milestone so we can track everything we want for a 1.0.0... — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/bradzacher/eslint-plugin-typescript/issues/151#issuecomment-439573183>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA29qyokHW8B8ldiBVrTQtDOpa3HrMcXks5uv2BigaJpZM4VzbDa> .

[bradzacher]

woo hoo 🎉
We're in a great spot now thanks to @armano2
Parser is up to date now and a lot of dead code was deleted.

Only a few more things to tidy up for the 1.0.0 release!

https://github.com/bradzacher/eslint-plugin-typescript/milestone/1

[armano2]

i started adding missing informations to AST, they are going to be required to make some of tslint rules.

• distinction for declare nodes: feat: fix issues in AST JamesHenry/typescript-estree#42
• type alias: feat: distinct type alias from variable in AST JamesHenry/typescript-estree#44

but this is not going to be available soon 😞

[bradzacher]

I was just looking at prettier-eslint and they have a hard reference to typescript-eslint-parser.

We should open an issue when we do the release to make sure they correct to the new parser ref

[guaizi149]

any info about v1.0? i want to use this recently.

[armano2]

we are almost there, we did alot of work in this weekend, you can see remaining tasks in milestone

you can help us by giving feedback for: recommended preset

[armano2]

@bradzacher @j-f1 what do you think about releasing beta version of package before we will go for 1.0.0 that we can get feedback from community about adjustments and errors?

[bradzacher]

Yes indeed! I'll be first publishing 1.0.0-rc.0 to the next tag, so that it can be tested before the official 1.0.0 release on latest.

[bradzacher]

1.0.0-rc.0 is live	on the next tag
Commit	7765028a500231d8d5903253619cc2ca19b98dbd
Tag	https://github.com/bradzacher/eslint-plugin-typescript/tree/1.0.0-rc.0
Release Notes	https://github.com/bradzacher/eslint-plugin-typescript/releases/tag/1.0.0-rc.0
NPM	https://www.npmjs.com/package/eslint-plugin-typescript/v/1.0.0-rc.0
Install	yarn add eslint-plugin-typescript@next
	npm i eslint-plugin-typescript@next

[armano2]

@bradzacher do we have any tasks left to do or we just have bug fixes?

[armano2]

what do you guys think about disabling typescript/interface-name-prefix from recommended,
its opinioned

[corbinu]

I would agree I have seen a lot of different formats

[bradzacher]

With most of the rules, we look to the typescript docs to figure out what the advice on what is best practice. The typescript team doesn't prefix names with I https://www.typescriptlang.org/docs/handbook/interfaces.html

Using IName is a convention that stems from the java/c#. This makes sense in those languages, because an interface has a very specific use, so you don't want people to confuse a concrete type with an interface.

However typescript has no such legacy. And interfaces exist purely as a marker for object shapes. Additionally interfaces are mostly interchangeable with types.
Additionally with interfaces allowing constructor fields, you can actually let people confuse an interface with a concrete class!

The interchangeability coupled with the fact that they are compile time only makes the I name prefix an antipattern in TS (much like Hungarian notation!).

[bradzacher]

1.0.0-rc.1 is live	on the next tag
Commit	867df2ed6fb1d8a1de1771710a9b92ee1f63977b
Tag	https://github.com/bradzacher/eslint-plugin-typescript/tree/1.0.0-rc.1
Release Notes	https://github.com/bradzacher/eslint-plugin-typescript/releases/tag/1.0.0-rc.1
NPM	https://www.npmjs.com/package/eslint-plugin-typescript/v/1.0.0-rc.1
Install	yarn add eslint-plugin-typescript@next
	npm i eslint-plugin-typescript@next

[bradzacher]

Alrighty everyone.
Once we merge #274 to fix missing cases in indent, I think we're in a good place to release 1.0.0 official.

People have been using it for a few weeks now and there aren't any open issues outside of parser bugs.

We could potentially wait for the new parser version to release to fix some of those open issues, but looking at them; it looks like they're rarer edge cases.

Thoughts? Objections?

[bradzacher]

1.0.0-rc.2 is live	on the next tag
Commit	4245290cb2b700c21a9c38adb318d6b12b8401bb
Tag	https://github.com/bradzacher/eslint-plugin-typescript/tree/1.0.0-rc.2
Release Notes	https://github.com/bradzacher/eslint-plugin-typescript/releases/tag/1.0.0-rc.2
NPM	https://www.npmjs.com/package/eslint-plugin-typescript/v/1.0.0-rc.2
Install	yarn add eslint-plugin-typescript@next
	npm i eslint-plugin-typescript@next

[SimenB]

Hey there! I see you're baking in the parser - will babel-eslint keep working like it does? I'd guess yes, the AST should still be compliant. Just making sure 🙂

This plugin allowed us to drop tslint at work, awesome job! 👍

(full proper support for TS in babel-eslint is coming here: babel/babel-eslint#711)

[armano2]

@SimenB, we are improving compatibility of AST between babel and typescript-eslint-parser

• https://github.com/eslint/typescript-eslint-parser/pulls

babel-eslint will need way more work, scope-analysis is not even started for TS

[j-f1]

Also, our parser will have type metadata from TS, which Babel will probably never have.

[SimenB]

Thanks for the replies!
I guess using overrides and specifying another parser is fine for the TS parts of our code base if there are actual features we miss out on (if type metadata matters)

[bradzacher]

@SimenB Unless I'm mistaken, you don't get any additional features from using babel-eslint, just support for new language features?

As long as you're not using any super duper bleeding edge JS features via babel transforms, then the typescript parser should work fine across your entire codebase (even on .js files).

[SimenB]

using Flow

[j-f1]

Should we switch the recommended config to only use our parser on .ts and .tsx parsers?

[armano2]

@SimenB you can specify separate parsers for extensions with eslint overrides.

for js/jsx use babel for ts, tsx

[armano2]

@j-f1 typescript provides/will provide type informations for js files

[SimenB]

Yeah, I'll to that. Thanks for the response!

[j-f1]

PR to eslint-config-prettier has been merged 🎉

[bradzacher]

1.0.0-rc.3 is live	on the next tag
Commit	162fddc10d6578805c6dc6b838ebcdbb7a4b336b
Tag	https://github.com/bradzacher/eslint-plugin-typescript/tree/1.0.0-rc.3
Release Notes	https://github.com/bradzacher/eslint-plugin-typescript/releases/tag/1.0.0-rc.3
NPM	https://www.npmjs.com/package/eslint-plugin-typescript/v/1.0.0-rc.3
Install	yarn add eslint-plugin-typescript@next
	npm i eslint-plugin-typescript@next

This will likely be the final RC release for 1.0.0

[ivanvoznyakovsky]

typescript-eslint-parser has moved to @typescript-eslint/parser and will no longer receive updates like support of new versions of typescript. proof

[stekycz]

Hi, is it possible to change peer dependency on TypeScript package from ~3.1.1 to >=3.1.1 < 4.0.0? The current TypeScript package version is 3.2.4. I would expect the first stable release to be able to be used with the latest stable releases of all peer dependencies.

[j-f1]

We’re going to be migrating this repo too @ivanvoznyakovsky.

@stekycz We’ll probably do that once we make sure our parser supports TypeScript 3.2.

[JamesHenry]

The plugin was merged FYI, and all packages are using TypeScript 3.2 :)

[bradzacher]

I'll make a proper announcement in a short while.
But yes, this repo is going to be archived, as the project is being merged into a mono repo at https://github.com/typescript-eslint/typescript-eslint/

[bradzacher]

@stekycz note that typescript doesn't completely follow true semver (they often release small breaking changes with minor version bumps), so having an open range on 3.x could cause bugs.

[JamesHenry]

Version 1.0.0 was released :)