search

tosdr / tosdr-firefox

Moved, see https://github.com/tosdr/browser-extensions
http://tosdr.org/downloads.html
GNU Affero General Public License v3.0
71 stars 13 forks source link

Merge this repo into gh:tosdr/browser-extensions #59

Open michielbdejong opened 6 years ago

michielbdejong commented 6 years ago

Since this repo now contains a WebExtension that gets built for both Firefox and Chrome, we can move it to the browser-extensions repo. I'm just waiting to either close all outstanding issues or move them over to that other repo as well, then we can deprecate this one.

shybyte commented 6 years ago

@michielbdejong I wonder if this a good moment to reformat/lint the whole code (except the libraries).

The current formatting is totally inconsistent:

Personally I'm afraid of such code bases, because it's difficult to read and I'm afraid to reformat by accident the whole file and mess up the git history completely for a one line change.

Such inconsistencies also lead to errors, that would be easily preventable by a simple linter. Example (like it looks in my editor):

              if (err.message = 'no domain name provided') {
    return;
   }

In would propose to use

as npm devDependencies to get and keep the code in a good consistent shape.

I would volunteer to do this job, but this would mean, that afterwards the git history of every line contains me. Would be OK for me, but I don't' want to steal the fame of anyone. However, there is time in every project where a complete reformat is necessary to ease future development and contributing. And then it's better to do this as early as possible.

michielbdejong commented 6 years ago

I did https://github.com/tosdr/browser-extensions/pull/21 as a first step. Need to clean up issues/PRs of this repo and then mark it as deprecated.

Vinnl commented 6 years ago

@shybyte You can always go further back in the commit history to find the original author, so I wouldn't worry about that :) (Or well, you can after my PR is merged ;) )

That said, it's probably best to do this if nobody's working on anything (i.e. when @michielbdejong is done with the migration), because otherwise you're bound to run into merge conflicts.