JSHint support #65

XhmikosR · 2012-10-30T17:14:19Z

No description provided.

evilstreak · 2013-04-21T20:46:08Z

lib/markdown.js

@@ -535,12 +537,12 @@ Markdown.dialects.Gruber = {
          // We have to grab all lines for a li and call processInline on them
          // once as there are some inline things that can span lines.
          var li_accumulate = "";
+          var nl = "",
+              l = lines[line_no].replace(/^\n/, function(n) { nl = n; return ""; });


This change will affect the behaviour, since it's no longer resetting nl and calculating l at the start of each loop.

evilstreak · 2013-04-21T20:53:31Z

In general, the changes look good and I'm in favour of them. There's a few I have issue with, most notably those that change the behaviour of the code!

If you have the time and inclination to look at this in the next week that'd be great, otherwise I'll make the suggested modifications when I get a chance and merge it in.

XhmikosR · 2013-04-22T06:12:47Z

Hi. I'll improve the PR soon and cc you.

XhmikosR · 2013-04-22T07:10:24Z

cc @evilstreak.

I added JSHint support properly. I also reverted the changes you commented.

Please check .jshintrc and let me know if you want me to change anything.

evilstreak · 2013-04-22T08:22:46Z

@XhmikosR Thanks for the update.

When I check out your branch and run npm run-script lint I get 111 errors, mostly about indentation. Is that what you expect?

I only have one comment about .jshintrc, which is that when I said the library is expected to work in environments like Node, lib/markdown.js is also expected to work in browsers. Can you set node: false just for that file?

XhmikosR · 2013-04-22T08:33:15Z

@evilstreak: I have changed that just before you try it. Please check out the branch again.

Personally, I'd like to have "curly": true, "indent": 2 but it's your call.

EDIT: Now the PR should be final.

evilstreak · 2013-04-22T13:06:50Z

This pull request is starting to get a little busy!

Tap 0.4.1 behaves oddly (no output by default, doesn't seem to run all the test files, and incredibly slow to exit after running tests) compared to the previous version I had installed (0.3.3 behaves as I'm used to). I'd like to investigate this further before updating the dependency.

The changes to the README are in general fine, though the list item indentation change doesn't seem right (it's gone from 4-space indent to a 5-space indent).

The changes to both lib/markdown.js and the tests to improve consistency and strictness seem good, though I think the jshint options in lib/markdown.js are still wrong — the code in that file should work whether it's being run in the browser or in node, so jshint should assume global variables from neither environment (i.e. browser: false, node: false, unless I've misunderstood those flags).

Finally, I'm hesitant to add an npm run-script lint task that is producing a lot of warnings out of the box.

In conclusion: I'd prefer multiple smaller (more focused!) pull requests over one large one. I think several of your changes are immediately pullable, or very close to pullable, and some are further off.

I'd accept a pull request right now that consisted solely of the code improvement changes, without the changes to package.json and README.md. For the other three changes (updating dependencies, updating the README, and adding a lint task), I'd prefer to see new pull requests so we can get them smoothed out before pulling.

XhmikosR · 2013-04-22T15:03:46Z

For tap, we can specify another version, but it's better to follow semver than using 0, or 1.

For the Readme, no indentation is needed for the lists; I'd personally remove the indentation.

We have browser: false in .jshintrc but for markdown.js browser is true. I think it's fine.

The lint task is one with the code changes. Without it you have to do it randomly. The warnings are not so many, and with a few more tweaking they can be reduced more.

I split the changes. The PR's are dependent so I will need to rebase if one is merged before merging the next one.

XhmikosR · 2013-04-26T18:03:15Z

I added a couple more commits. I'm not sure if this is the style you prefer, but now it's consistent by using brackets.

Let me know your thoughts.

ashb · 2013-04-29T12:11:21Z

test/regressions.t.js

@@ -482,7 +482,7 @@ test( "inline_link", function(t, md) {
                                  [ [ "link", { href: "url", title: "tit'le" }, "text" ], " after')" ],
                                  "inline link III" );

-  t.equivalent( md.processInline( "[text](url \"title\")" ),
+  t.equivalent( md.processInline( "[text](url 'title')" ),


This change and the one one line 454 is wrong.

If you desperately don't want \" then change the whole thing to single quotes, not the double quote in the string to single quotes.

I don't see it wrong. It gets rid of the unnecessary escape.

You are changing the input to a test from (url "title") to (url 'title') - this is no longer testing the same thing.

OK then, I'll revert this part when I manage to rebase against master.

ashb · 2013-04-29T12:14:56Z

I disagree with the re-indentation in 7ad51bd - indenting the entire file for the (function( expose ) { is pointless in my view.

ashb · 2013-04-29T12:15:41Z

@XhmikosR could you rebase this pull request against master - I'm not quite sure which (if any?) parts of this have been included in other pull requests etc.

Thanks!

XhmikosR · 2013-04-29T12:38:53Z

@ashb: now it should be ok. The indentation patch is now much smaller since I only changed the part that used 4 spaces instead of 2 like most of the code does.

XhmikosR · 2013-06-01T06:19:36Z

PR updated.

XhmikosR · 2013-07-27T05:49:40Z

Bump

ashb · 2013-07-27T09:03:58Z

Apologies for letting this lie fallow for so long - we've been rather distracted with other things :(

According to travis this branch is failing its tests while master is currently passing https://travis-ci.org/evilstreak/markdown-js/builds/9542984. The error rather confusing:

Cannot call method 'replace' of undefined at /home/travis/build/evilstreak/markdown-js/lib/markdown.js line 393

We're we waiting on @evilstreak's (browser) test refactor for this or was that something else?

XhmikosR · 2013-07-27T13:59:03Z

@ashb: No worries, I understand you both are busy people.

I noticed that the tests are failing, but since @evilstreak suggested to use tap @0.3.3 I cannot test things on Windows; it always failed for me. I need to use tap 0.4.3 to actually see the failed tests.

EDIT:

I can't see something wrong with my changes, but I'm missing something probably. Or it's the strict comparisons used.

XhmikosR · 2013-07-28T08:37:27Z

The issue with the failing tests seems to come from this. I removed for now until someone else has a look.

EDIT: Travis still fails and the JSHint warnings must be related.


> [email protected] check C:\Users\xmr\Desktop\markdown-js
> jshint .

lib\markdown.js: line 265, col 5, 'blocks' is already defined.
lib\markdown.js: line 265, col 13, 'blocks' is a statement label.
lib\markdown.js: line 266, col 34, 'blocks' is a statement label.
lib\markdown.js: line 266, col 50, 'blocks' is a statement label.
lib\markdown.js: line 379, col 76, Don't make functions within a loop.
lib\markdown.js: line 578, col 85, Don't make functions within a loop.
lib\markdown.js: line 652, col 71, 'nl' used out of scope.
lib\markdown.js: line 824, col 14, 'res' is already defined.
lib\markdown.js: line 927, col 15, 'link' is already defined.
lib\markdown.js: line 1109, col 32, ['__'] is better written in dot notation.
lib\markdown.js: line 1111, col 32, ['_'] is better written in dot notation.
lib\markdown.js: line 1117, col 3, The body of a for in should be wrapped in an if statement to filter unwanted properties from the prototype.
lib\markdown.js: line 1130, col 3, The body of a for in should be wrapped in an if statement to filter unwanted properties from the prototype.
lib\markdown.js: line 1249, col 30, Expected a 'break' statement before 'default'.
lib\markdown.js: line 1276, col 9, Creating global 'for' variable. Should be 'for (var p ...'.
lib\markdown.js: line 1276, col 3, The body of a for in should be wrapped in an if statement to filter unwanted properties from the prototype.
lib\markdown.js: line 1317, col 11, Creating global 'for' variable. Should be 'for (var a ...'.
lib\markdown.js: line 1317, col 5, The body of a for in should be wrapped in an if statement to filter unwanted properties from the prototype.
lib\markdown.js: line 1337, col 9, Creating global 'for' variable. Should be 'for (var a ...'.
lib\markdown.js: line 1337, col 3, The body of a for in should be wrapped in an if statement to filter unwanted properties from the prototype.
lib\markdown.js: line 1359, col 13, 'm' is already defined.
lib\markdown.js: line 1393, col 29, Expected a conditional expression and instead saw an assignment.
lib\markdown.js: line 1405, col 38, Expected a conditional expression and instead saw an assignment.
lib\markdown.js: line 1413, col 15, 'table' is already defined.
lib\markdown.js: line 1482, col 3, The body of a for in should be wrapped in an if statement to filter unwanted properties from the prototype.
lib\markdown.js: line 1599, col 3, The body of a for in should be wrapped in an if statement to filter unwanted properties from the prototype.
lib\markdown.js: line 1627, col 5, The body of a for in should be wrapped in an if statement to filter unwanted properties from the prototype.
lib\markdown.js: line 1710, col 15, 'ref' is already defined.
lib\markdown.js: line 1738, col 5, The body of a for in should be wrapped in an if statement to filter unwanted properties from the prototype.
lib\markdown.js: line 122, col 11, 'uneval' is not defined.
lib\markdown.js: line 124, col 11, 'uneval' is not defined.
lib\markdown.js: line 126, col 11, 'uneval' is not defined.
lib\markdown.js: line 1277, col 20, 'p' is not defined.
lib\markdown.js: line 1318, col 13, 'a' is not defined.
lib\markdown.js: line 1318, col 25, 'a' is not defined.
lib\markdown.js: line 1338, col 11, 'a' is not defined.
lib\markdown.js: line 1338, col 23, 'a' is not defined.

test\features.t.js: line 40, col 11, The body of a for in should be wrapped in an if statement to filter unwanted properties from the prototype.
test\features.t.js: line 54, col 9, Don't make functions within a loop.
test\features.t.js: line 26, col 5, The body of a for in should be wrapped in an if statement to filter unwanted properties from the prototype.
test\features.t.js: line 82, col 1, The body of a for in should be wrapped in an if statement to filter unwanted properties from the prototype.
test\features.t.js: line 44, col 17, 'text' is not defined.
test\features.t.js: line 49, col 47, 'text' is not defined.

test\regressions.t.js: line 48, col 5, 'h2' is not defined.

44 errors

XhmikosR · 2013-08-16T07:42:05Z

bump No 2...

I haven't fixed the Travis failures; I'd rather one of you @evilstreak @ashb have a look.

I'm pretty sure they are caused because of the undefined variables like blocks, etc.

As you can see JSHint isn't just for missing semicolons :P

ashb · 2013-08-16T09:31:18Z

God we're awful at this open source development lark. Sorry.

Good news is that evilstrak and I are planning on spending some time hacking next week - this will be one of the first things we look at.

XhmikosR · 2013-08-16T09:44:30Z

OK, good to hear that. Let me know if you need any changes in the PR.

I decided to use JSHint's feature to load its config from package.json instead of using a separate file.

Use `npm run check` or `npm run lint`.

ashb · 2013-08-22T19:04:57Z

Thanks - I didn't use most of the commits directly - a few commits I cherry picked, a few I just did differently.

I've also added you to the contributors section in the package.json

XhmikosR · 2013-08-22T19:22:12Z

Thanks for looking into the PR.

The thing with your way is that I dont show as the patch author...

You could have told me if you wanted me to make any changes, but anyway I'm glad the PR is merged.

evilstreak reviewed Apr 21, 2013
View reviewed changes

ashb reviewed Apr 29, 2013
View reviewed changes

XhmikosR added 6 commits August 22, 2013 19:47

Add JSHint support.

20c56e4

Use `npm run check` or `npm run lint`.

Fix many JSHint warnings.

d703d12

JSHint: Enable curly rule.

ac9de00

Get rid of node.js v0.9 from travis; it was buggy and not stable.

00f5d9d

package.json: Specify the minimum node.js version.

a3636d9

Explicitly specify the npm package contents.

b97a226

GitHub is using https links, so use that.

693261c

ghost assigned ashb Aug 22, 2013

ashb closed this in 866e281 Aug 22, 2013

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

JSHint support #65

JSHint support #65

XhmikosR commented Oct 30, 2012

evilstreak Apr 21, 2013

evilstreak commented Apr 21, 2013

XhmikosR commented Apr 22, 2013

XhmikosR commented Apr 22, 2013

evilstreak commented Apr 22, 2013

XhmikosR commented Apr 22, 2013

evilstreak commented Apr 22, 2013

XhmikosR commented Apr 22, 2013

XhmikosR commented Apr 26, 2013

ashb Apr 29, 2013

XhmikosR Apr 29, 2013

ashb Apr 29, 2013

XhmikosR Apr 29, 2013

ashb commented Apr 29, 2013

ashb commented Apr 29, 2013

XhmikosR commented Apr 29, 2013

XhmikosR commented Jun 1, 2013

XhmikosR commented Jul 27, 2013

ashb commented Jul 27, 2013

XhmikosR commented Jul 27, 2013

XhmikosR commented Jul 28, 2013

XhmikosR commented Aug 16, 2013

ashb commented Aug 16, 2013

XhmikosR commented Aug 16, 2013

ashb commented Aug 22, 2013

XhmikosR commented Aug 22, 2013

JSHint support #65

JSHint support #65

Conversation

XhmikosR commented Oct 30, 2012

evilstreak Apr 21, 2013

Choose a reason for hiding this comment

evilstreak commented Apr 21, 2013

XhmikosR commented Apr 22, 2013

XhmikosR commented Apr 22, 2013

evilstreak commented Apr 22, 2013

XhmikosR commented Apr 22, 2013

evilstreak commented Apr 22, 2013

XhmikosR commented Apr 22, 2013

XhmikosR commented Apr 26, 2013

ashb Apr 29, 2013

Choose a reason for hiding this comment

XhmikosR Apr 29, 2013

Choose a reason for hiding this comment

ashb Apr 29, 2013

Choose a reason for hiding this comment

XhmikosR Apr 29, 2013

Choose a reason for hiding this comment

ashb commented Apr 29, 2013

ashb commented Apr 29, 2013

XhmikosR commented Apr 29, 2013

XhmikosR commented Jun 1, 2013

XhmikosR commented Jul 27, 2013

ashb commented Jul 27, 2013

XhmikosR commented Jul 27, 2013

XhmikosR commented Jul 28, 2013

XhmikosR commented Aug 16, 2013

ashb commented Aug 16, 2013

XhmikosR commented Aug 16, 2013

ashb commented Aug 22, 2013

XhmikosR commented Aug 22, 2013