Update package.json to point to htmlparser2 fork

[danielbrzn]

Change the dependency in package.json to point to Markbind's fork of htmlparser2 that includes fixes for Markdown-in-HTML parsing.

Follows MarkBind/htmlparser2#1

Resolves#101

[acjh]

Can you share the link of the article that you showed me?

[danielbrzn]

Forking NPM modules

[acjh]

I'm not sure how versioning would work with tarball/master.

Maybe we should use commits (or tags; both mentioned in your link) to target specific versions.

@Gisonrg Your thoughts?

[danielbrzn]

I think it would pull the latest version of the master instead of a specific version which I feel is more ideal as we don't have to keep updating the link in package.json.

[acjh]

which I feel is more ideal as we don't have to keep updating the link in package.json.

That's not ideal. It will be hard to debug errors if an earlier version of MarkBind is used with a later version of htmlparser2 (or any other library). There's a reason why packages are always published with a package.json that points to specific known-working versions of other packages.

[Gisonrg]

I think it would pull the latest version of the master instead of a specific version which I feel is more ideal as we don't have to keep updating the link in package.json.

Even though it might work in some cases, this is not an ideal practice in general :)
If you always depends on the latest version (or snapshot) of a library, you may have issues regarding compatibility. Suppose you change the API in your library in one commit but does not update the usage for your users (e.g. MarkBind), all usages in user library might not work due to the change.
In production system, you won't release a version that's under active development. That's why they usually have "release" branches which are stable build after testing.
Also, if you have multiple engineers in the team use different version of a library but working in the same project, and they don't know about that (because they all pull from latest version at the time of their pull), one might expect inconsistent behaviour of the library due to different version.
That's exactly why we have to specific a version in the package.json, to ensure consistency across all users.

[danielbrzn]

I see. Should we tag a version of our htmlparser2 fork and use it in ourpackage.json instead?

[acjh]

Sure. Let's use pre-release versioning as per the Semantic Versioning guidelines.
Since the current version of htmlparser2 is v3.9.2, I propose v3.10.0-markbind.1.

_{Note: We can consider versioning MarkBind/vue-strap too.}

[acjh]

Can you add "Follows MarkBind/htmlparser2#1" in the PR description?

[acjh]

Can you add "Resolves #101" in the PR description?

[danielbrzn]

Added.

Just to clarify, the version number in package.json should read as follows?

 "htmlparser2": "^v3.10.0-markbind.1",

[acjh]

No, that's if you publish as htmlparser2 in the npm registry.
The website you linked suggests a form that it should take.

[Gisonrg]

I believe if we push a new tag (like the v3.10 here) to the head of repo, we can do something like:

"htmlparser2": "MarkBind/htmlparser2#v3.10.0",

[danielbrzn]

Yep that works! The tag is v3.10.0-markbind.1, will be changing it.

[acjh]

Commit package-lock.json too.

[Gisonrg]

Can we get rid of the https://github.com/ part?

The "author/repo" format should be supported by npm

[acjh]

@danielbrzn Thanks for your contribution!

[acjh]

@danielbrzn I just noticed the bad integrity checksum changes (fixed). You may need to upgrade npm.

[danielbrzn]

Odd. What version of npm are you running? I have v5.6.0.

[acjh]

v5.6.0 as well. See npm/npm#16938 (comment).