-
-
Notifications
You must be signed in to change notification settings - Fork 175
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
Support TypeScript v4.x #402
Comments
I feel like we could switch this dependency to instead be a peerDependency The only downside to this would be that, since we're probably not likely to keep track of how each TS version affects this package, we'll eventually have the ceiling reported to us and we'd have to change the range until a fix comes into play. I think this is still better than forcing consumers into multiple versions of TS |
It's a good idea to give flexibility to the user, but I don't know the effect on the package @typescript-eslint/parser |
They follow One very interesting question is... where do we stand in regards to SemVer on this? Should we bump a major if we upgrade We could also probably change the way this library works in terms of... maybe we list the key dependencies ( Could drastically lower the amount of activity in this project's issues/PRs... |
If we make it a peer dependency. What should we use for the tests ? Should we only use the latest version? |
@hamzahamidi keep in mind neither of those repositories follow SemVer. There aren't breaking changes in v4. And yeah, I think latest for our own repo is fine. |
Note #133 and the decision zimme reached, but I respectfully disagree, since we have 3 years of other issues to point to as evidence. |
If problems are actually solved by moving prettier amd eslint into peer dependencies I don't have a problem with that. As we do use prettier and eslint in the closest node_modules from the directory where prettier-eslint is run. Maybe it actually makes sense to have the dependencies as peer dependencies to make sure you have a copy of prettier and eslint there. However Im not sure this will actually solve the problems people are facing as if they want to use another version they can just manually install prettier and eslint in their projects and those versions will be used. Maybe we shouldnt be using our current approch of resolving prettier and eslint. The only way to be sure of the best way is probably to try in alpha releases |
My guess would be that a large amount of people that use this dependency aren't aware of the ability to use The bigger hope from me is that this shrugs off this library's responsibility for ensuring the two pair well. Instead, we're just the system of enforcing: lint first, format second. We'll release its a breaking alpha. |
The reason I think, could be wrong here, the decision was made to make sure the two play nice is that prettier-eslint isnt just providing format first, auto fix second, but it also provides functionality to infer prettier options from eslint configs. |
Awesome. I'll write that in the README to explain the differences. |
Here's another issue that peerDeps would solve: There's several subtle errors that can't be fixed until
It would be fine if prettier-eslint team was on top of every release, but historically it hasn't been. I'm not trying to throw blame or anything, just making a point that peerDeps would at least allow users to solve incompatibility users by pinning their own version lest be stuck with the version that prettier-eslint decided. |
Couldn't |
@kylemh Relying on a |
https://github.com/rogeriochaves/npm-force-resolutions just trying to give you a workaround for now. @zimme I haven't used |
I don't really use this library any longer as I don't need my prettier setting being inferred from my eslint settings, which is what this library provides over just using prettier && eslint --fix. So there is still a "need" for this package but the recommended way of using prettier with eslint is to actually use eslint-config-prettier which disables all eslint rules that conflict with prettier. |
I think it would be a good idea to update the readme with a recommendation to use prettier, eslint and eslint-config-prettier directly unless you want the prettier config to be changed based on your eslint config. |
I guess there's also a use case for this lib in editors which don't support multiple linter/formatters on one file type |
As for this specific issue. I do believe we walt to changed all the typescript/vue/other parsers to optional dependencies and check if thery're available and only use them in those cases. As well as loosening the version ranges on those dependencies. |
It didn't seem like https://docs.npmjs.com/cli/v7/configuring-npm/package-json#optionaldependencies
Gave it a whirl though: #505 👀 |
Quick follow up: I switched to yarn and tried
So that's a no go. I think @kylemh's #505 is the way to go moving forward. Or, is this library just not recommended to be used anymore? Should it be deprecated in favor of an |
I use this library for this reason. I have a Visual Studio Code plugin I wrote before the Prettier extension supported ESLint formatting. Plus people have flocked to mine because it's easier to setup. |
close in favor of #696 |
Versions:
prettier-eslint
version:11.0.0
Problem description:
TypeScript has recently released a new update which bumped the major. Unfortunately, TypeScript doesn't adhere to semver (see microsoft/TypeScript#14116). This unfortunately means that if a user's project depends on TypeScript v4.0, npm/yarn will install a separate TypeScript v3.9 just for this package in order to fulfill the dependency version ranges.
Suggested solution:
Using
>=3.9.2
as the dependency version for thetypescript
package should fix this issue while keeping keeping the option to use older, still compatible TypeScript versions. See https://docs.npmjs.com/files/package.json#dependencies.Relevant: #391
The text was updated successfully, but these errors were encountered: