Skip to content
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

dartfix #8125

Closed
DartBot opened this issue Jan 25, 2013 · 0 comments
Closed

dartfix #8125

DartBot opened this issue Jan 25, 2013 · 0 comments
Labels
closed-not-planned Closed as we don't intend to take action on the reported issue type-enhancement A request for a change that isn't a bug

Comments

@DartBot
Copy link

DartBot commented Jan 25, 2013

This issue was originally filed by jjinux...@google.com


This is in response to some problems I encountered when trying to update my code to libv2.

Go has gofix. We have a bunch of cleanups in the editor. They are very good, and I am very grateful to the editor team for them. However, perhaps we should do something a bit more industrial strength and foolproof. Perhaps we should be more like gofix.

Here's my suggestion:

 * Let's move the fixes out of the editor and into a tool called dartfix.

 * Every Dart project should have a pubspec.yaml that contains the version of the SDK that it is known to work with.

 * Whenever a breaking API change is made, the person making the API change is responsible for adding a fix to dartfix. The fix would use dart2dart to automatically fix the code.

 * Every time the user updates his SDK, the editor could run dartfix so that all of the correct Dart fixes would be applied.

 * dartfix would update some file to record that the fixes had been applied.

This would solve a few problems:

 * This would allow the libraries team to continue breaking APIs because the fixes would be applied to people's code automatically.

 * This would solve the problem of people not knowing when they need to apply cleanups and whether certain cleanups had already been applied.

 * This would move more code out of Java (I'm guessing it's in Java) and make the code reusable outside the editor.

 * This would put the engineer who breaks the API in charge of fixing people's code, which is probably more likely to be successful than the editor guys always trying to play catchup.

@sethladd sethladd added the closed-not-planned Closed as we don't intend to take action on the reported issue label Jul 10, 2015
@kevmoo kevmoo added type-enhancement A request for a change that isn't a bug and removed triaged labels Mar 1, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
closed-not-planned Closed as we don't intend to take action on the reported issue type-enhancement A request for a change that isn't a bug
Projects
None yet
Development

No branches or pull requests

3 participants