Version 1.0.0 about typescript-eslint HOT 43 CLOSED

@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?

from typescript-eslint.

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!).

from typescript-eslint.

@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.

from typescript-eslint.

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

from typescript-eslint.

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.

from typescript-eslint.

from typescript-eslint.

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

from typescript-eslint.

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.

from typescript-eslint.

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

from typescript-eslint.

@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).

from typescript-eslint.

using Flow

from typescript-eslint.

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

for js/jsx use babel for ts, tsx

from typescript-eslint.

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

from typescript-eslint.

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.

from typescript-eslint.

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

from typescript-eslint.

@bradzacher Amazing, thanks.

from typescript-eslint.

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

from typescript-eslint.

@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.

from typescript-eslint.

@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

from typescript-eslint.

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...

from typescript-eslint.

from typescript-eslint.

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

• distinction for declare nodes: JamesHenry/typescript-estree#42
• type alias: JamesHenry/typescript-estree#44

but this is not going to be available soon 😞

from typescript-eslint.

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

from typescript-eslint.

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

from typescript-eslint.

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

from typescript-eslint.

I would agree I have seen a lot of different formats

from typescript-eslint.

from typescript-eslint.

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?

from typescript-eslint.

from typescript-eslint.

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)

from typescript-eslint.

@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

from typescript-eslint.

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

from typescript-eslint.

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)

from typescript-eslint.

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

from typescript-eslint.

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

from typescript-eslint.

PR to eslint-config-prettier has been merged 🎉

from typescript-eslint.

This will likely be the final RC release for 1.0.0

from typescript-eslint.

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

from typescript-eslint.

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.

from typescript-eslint.

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

from typescript-eslint.

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/

from typescript-eslint.

@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.

from typescript-eslint.

Version 1.0.0 was released :)

from typescript-eslint.