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

Introduce 'make doclint' command and tooling #8551

Closed
wants to merge 1 commit into from

Conversation

ChALkeR
Copy link
Member

@ChALkeR ChALkeR commented Sep 15, 2016

Checklist
  • make -j4 test (UNIX), or vcbuild test nosign (Windows) passes
  • documentation is changed or added
  • commit message follows commit guidelines
Affected core subsystem(s)

tools

Description of change

Note: there were some more changes in this PR, those were extracted to #8660, #8553, #8666, and were merged already.

Add remark-cli and remark-lint to tools/remark-cli, introducing new make mdlint command.

make mdlint now lints all docs, make test now executes make mdlint.

A complete make mdlint check takes 8-9 seconds on my notebook.

Previous work in #7729.

/cc @Trott, @jasnell, @addaleax.

@ChALkeR ChALkeR added doc Issues and PRs related to the documentations. tools Issues and PRs related to the tools directory. labels Sep 15, 2016
@nodejs-github-bot nodejs-github-bot added build Issues and PRs related to build files or the CI. tools Issues and PRs related to the tools directory. labels Sep 15, 2016
@Trott
Copy link
Member

Trott commented Sep 15, 2016

Should there be a vcbuild.bat mdlint for Windows users?

@ChALkeR
Copy link
Member Author

ChALkeR commented Sep 17, 2016

Rebased. @Trott, I don't think I would be able to test vcbuild.bat on my PC, so perhaps it would be better if someone with a Windows setup made it.

@Trott
Copy link
Member

Trott commented Sep 18, 2016

@ChALkeR I don't have direct access to Windows either, but in the past, if it's just one or two lines, I've updated vcbuild.bat and then posted in the GitHub tracker asking someone on Windows to try it out, and that usually works. (Nothing wrong with your approach either! Just suggesting another option.)

/cc @nodejs/platform-windows

@addaleax
Copy link
Member

This should probably get all the dont-land-on-v?.x labels because this is an almost purely additional change and we’re not eager to backport the doc cleanups, right? I’m setting them but feel free to remove if you think that’s not a good idea.

Also, did you check whether the dependencies here end up in the distribution tarballs?

@ChALkeR
Copy link
Member Author

ChALkeR commented Sep 20, 2016

@addaleax Thanks, I didn't think of that.

I will split this into two separate PRs — the actual rules update that would allow me to file more pull requests with fixes without conflicts in the config file, and the make mdlint tooling that would probably consist of separate commits that I would squash on landing.

@ChALkeR ChALkeR mentioned this pull request Sep 20, 2016
2 tasks
@jasnell
Copy link
Member

jasnell commented Sep 20, 2016

Awesome! I won't sign off on this just yet as I haven't had a chance to review but I'm very happy to see this.

@jbergstroem
Copy link
Member

Is it possible to get a -ci representation that spits out tap13?

@wooorm
Copy link

wooorm commented Sep 23, 2016

Thanks for using remark, folks! 🎉
Please ping me if something’s broken / want my advice or input on anything!

@Trott
Copy link
Member

Trott commented Sep 23, 2016

I'm OK with this landing without a vcbuild implementation or a doclint-ci job just as long as we open separate issues for those things (and maybe tag them help wanted and/or good first contribution as appropriate).

Rubber-stamp LGTM if CI is fine (which I imagine is really just going to make sure that the .eslintignore stuff is working and that this doesn't accidentally break the Makefile).

@ChALkeR ChALkeR changed the title Introduce 'make mdlint' command and tooling Introduce 'make doclint' command and tooling Sep 25, 2016
This adds remark-lint tooling and introduces a 'make doclint' command,
which is also executed on 'make test' runs.

tools/remark-cli dir was created by installing `remark-cli` and
`remark-lint`, the following files and directories are being excluded:
 * `./node_modules/concat-stream/node_modules/readable-stream/`
   a duplicate copy of `readable-stream` of 2.0, there already is 2.1.
 * `./**/doc/`, `./**/test/` -- docs and tests for deps are not needed.
 * `./**/history.md` and `./**/changelog.md` (case-insensitive).
 * `./**/.travis.yml`, `./**/.istanbul.yml`, `./**/.zuul.yml`.
 * `./**/.eslintrc`, `./**/.jscs.json`, `./**/.jshintrc`.
 * `./**/.npmignore`, `./**/component.json`, `./**/.gitattributes`.
 * `./**/dist/` (affects `sprintf-js` and `js-yaml`), not `require()`-d.

PR-URL: nodejs#8551
@ChALkeR
Copy link
Member Author

ChALkeR commented Sep 25, 2016

Renamed to make doclint.

Todo:

  • Make sure this tooling doesn't get packed in the release tarball.
  • vcbuild.bat support.
  • doclint-ci

@ChALkeR ChALkeR mentioned this pull request Oct 4, 2016
3 tasks
@rvagg rvagg force-pushed the master branch 2 times, most recently from c133999 to 83c7a88 Compare October 18, 2016 17:02
@ChALkeR
Copy link
Member Author

ChALkeR commented Oct 26, 2016

This got stalled because of the CI support, I'm planning to:

  • postpone the CI integration to a separate PR,
  • postpone the vcbuild.bat support, as I currently can't test on Windows,
  • fix the other issues here soon.

@@ -123,6 +123,7 @@ test: all
$(MAKE) cctest
$(PYTHON) tools/test.py --mode=release -J \
addons doctool inspector known_issues message pseudo-tty parallel sequential
$(MAKE) doclint
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe rename to mdlint? I assume we want to lint every md, including non-doc files.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The thing is, there is a project named mdlint, and that's not the one we are using.

Copy link
Contributor

@silverwind silverwind Nov 9, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see that as an issue. There is a project called jslint and we happily use that name for js lint task 😉.

@silverwind
Copy link
Contributor

silverwind commented Nov 9, 2016

I'd suggest you split this in 2 commits, one for the module, one for config changes, so it's easier to review.

@silverwind
Copy link
Contributor

I'd suggest running dmn clean -f before committing those modules to save a few bytes:

remark-cli: OK: Done! Your node_modules directory size was 2860.10 Kb but now it's 2594.57 Kb which is 9.3% less.
remark-lint: OK: Done! Your node_modules directory size was 388.04 Kb but now it's 362.54 Kb which is 6.6% less.

@eljefedelrodeodeljefe
Copy link
Contributor

I find this to be unnecessary to be included into the tree. it's a lot of files and only adds value for linting. Would a npm install remark-lint@specific-version && ./node_modules/.bin/remark-linter not be enough? Also given the shaky nature of markdown processor development.

@silverwind
Copy link
Contributor

I'm not sure we can require a working npm to run tests. It'd certainly complicate the build process for distribution package maintainers.

@eljefedelrodeodeljefe
Copy link
Contributor

well it is possible if we don't run then through make and adopt practical Node testing behaviour. One could say this would require Node then, but it is available as binary or you just take the compiled one.

@Trott
Copy link
Member

Trott commented Nov 9, 2016

well it is possible if we don't run then through make and adopt practical Node testing behaviour.

Since we include eslint already, there's precedence for including large lint tools as dependencies in the tree. I can't think of a reason to handle eslint and remark differently.

If we want to change it for both, then that's a pretty big change with a lot to consider. (For example: Do we want our CI and release stuff to fail if the npm registry is down? I don't know the answer and this is not the only thing we'd need to consider.)

It may be a great idea--I have no opinion, at least not at this time--but I would prefer that such a change should be a separate PR so that just that practice (bundling the tools with our repository vs. installing them over the network with tools) is up for discussion. It would be a shame for a meta-issue like that (no matter how important) to stall this.

@eljefedelrodeodeljefe
Copy link
Contributor

eljefedelrodeodeljefe commented Nov 9, 2016

Well I think eslint is not comparable since it actually lints the actual language we are defining here. So that would functionally be more important than a Markup language that could be get rid of any time. That being said, yes they should be treated equally namely getting rid of eslint too.

There are more than checking in and installing as possibilities for CI. E.g. imaginable would be global dependencies on the node that get provisioned with the Node or a static Docker container.
Also our releases and builds are not time critical and they can be down for a while as does the rest of user and application land.

I wouldn't merge this until the meta issue is resolved. It's also a little funny that there is no meta issue yet, since we are seeing remark commits since the mid this year, always with hints "let's rather not rely on that tool". This was foreseeable.

@eljefedelrodeodeljefe
Copy link
Contributor

edit: also writing an external tool that could also include remark as dependency would be thinkable.

@jasnell
Copy link
Member

jasnell commented Jan 6, 2017

@ChALkeR ... next steps on this?

@Trott Trott mentioned this pull request Mar 1, 2017
2 tasks
@jasnell
Copy link
Member

jasnell commented Mar 1, 2017

Closing this in favor of #11610

@jasnell jasnell closed this Mar 1, 2017
ChALkeR added a commit to ChALkeR/io.js that referenced this pull request Mar 7, 2017
This adds remark-lint tooling and introduces a 'make doclint' command,
which is also executed on 'make test' runs.

tools/remark-cli dir was created by installing `remark-cli` and
`remark-lint`, the following files and directories are being excluded:
 * `./node_modules/concat-stream/node_modules/readable-stream/`
   a duplicate copy of `readable-stream` of 2.0, there already is 2.1.
 * `./**/doc/`, `./**/test/` -- docs and tests for deps are not needed.
 * `./**/history.md` and `./**/changelog.md` (case-insensitive).
 * `./**/.travis.yml`, `./**/.istanbul.yml`, `./**/.zuul.yml`.
 * `./**/.eslintrc`, `./**/.jscs.json`, `./**/.jshintrc`.
 * `./**/.npmignore`, `./**/component.json`, `./**/.gitattributes`.
 * `./**/dist/` (affects `sprintf-js` and `js-yaml`), not `require()`-d.

PR-URL: nodejs#8551
@ChALkeR
Copy link
Member Author

ChALkeR commented Mar 7, 2017

@jasnell, I still think that this should be done through using an already existing tool and rules, possibly extending the rules, if needed, and not writing and supporting our own markdown linter ruleset and toolset from the scratch.

I will probably file another remark-based PR from the same branch (can't reopen this one) after the Buffer issues get sorted out.

Alternatively, anyone else is free to take off based on https://github.com/ChALkeR/io.js/tree/remark, the main issue there was the missing TAP test results for the CI. 😉

Perhaps the remark modules need to be updated since then, too =).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
build Issues and PRs related to build files or the CI. doc Issues and PRs related to the documentations. tools Issues and PRs related to the tools directory. wip Issues and PRs that are still a work in progress.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants