The devDependency eslint-plugin-react was updated from 7.14.0 to 7.14.1.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

eslint-plugin-react is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

The devDependency webpack was updated from 4.35.3 to 4.36.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

webpack is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Hi! I'm interested in self-hosting Postlight Parser API on my local machine. Would you be accepting a pull request that adds:

• a simple web server (maybe express?) that serves the request; and
• Dockerfile?

(You might consider introducing some GitHub actions to deploy the official Docker image, but that's another story.)

The devDependency eslint-plugin-import was updated from 2.16.0 to 2.17.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

eslint-plugin-import is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

🚨 You need to enable Continuous Integration on Greenkeeper branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet. We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please click the 'fix repo' button on account.greenkeeper.io.

• Platform: AWS Lambda

Expected Behavior

When you POST a request with only the URL parameter. The response is UTF-8 friendly.
When I use the html parameter, response should be utf-8 friendly too.

The API should return a title like this : "Le démantèlement des réacteurs nucléaires, véritable filière industrielle"
And content like this :
... <p><strong>Dans les prochaines ann&#xE9;es, avec la transition &#xE9;nerg&#xE9;tique et le d&#xE9;mant&#xE8;lement ...

Current Behavior

Title returned : "Le d�mant�lement des r�acteurs nucl�aires, v�ritable fili�re industrielle"
Content returned:
...<p><strong>Dans les prochaines ann**&#xFFFD;**es, avec la transition &#xFFFD;nerg&#xFFFD;tique et le d&#xFFFD;mant&#xFFFD;lement ...

Steps to Reproduce

I just do a POST to the parse-html endpoint
{ "url": "https://www.europeanscientist.com/fr/energie/demantelement-reacteurs-nucleaires-dechets-pngmdr/", "html" : [copy_paste_of_html_code] }

Possible Solution

I tried to force header's request Content-type to utf-8 with application/json; charset=utf-8 but it doesn't change the result.
While running this request locally, I've got an Iconv-lite deprecation warning related to encoding
Iconv-lite warning: decode()-ing strings is deprecated. Refer to https://github.com/ashtuchkin/iconv-lite/wiki/Use-Buffers-when-decoding

Serverless: GET /parser (λ: mercuryParser)
Serverless: Failure: tunneling socket could not be established, statusCode=407
Error: tunneling socket could not be established, statusCode=407
at ClientRequest.onConnect (C:\Users\a662140\Desktop\Karan\mercury-parser-api\node_modules\request\node_modules\tunnel-agent\index.js:165:19)
at Object.onceWrapper (events.js:313:26)
at ClientRequest.emit (events.js:223:5)
at ClientRequest.EventEmitter.emit (domain.js:475:20)
at Socket.socketOnData (_http_client.js:490:11)
at Socket.emit (events.js:223:5)
at Socket.EventEmitter.emit (domain.js:475:20)
at addChunk (_stream_readable.js:309:12)
at readableAddChunk (_stream_readable.js:290:11)
at Socket.Readable.push (_stream_readable.js:224:10)
at TCP.onStreamRead (internal/stream_base_commons.js:181:23)

• Platform:
• Mercury Parser API Version:
• Node Version:

Expected Behavior

Current Behavior

Steps to Reproduce

Detailed Description

Possible Solution

Ran through an AWS lambda install this morning -- flawless, and worked great, right out of the box. Kudos for providing such a smooth path for transition for your users. Highly appreciated.

The one place I did get stuck for a while was setting the specific IAM/cloudformation permissions within the AWS console -- this took several tries to get right. It would be helpful to state (or link to) a sample of what the permissions required for AWS deploy are for this project.

• Mercury Parser API Version:Latest
• Node Version:8

Expected Behavior

The parser should not corrupt the <img> content.

Current Behavior

The <img> tag originally is

  <img src=\"https://cdn.example-domain.com/example1.jpg"/>

and after parsing

 <img src="https://www.example-domain.com/%22https://cdn.example-domain.com/example1.jpg/%22/">

Steps to Reproduce

1. Take the following HTML

<html>
<head>
<body>     
Main content
<br/>
<img src="https://cdn.example-domain.com/example1.jpg"/>
More content
<br/>
More Content to Simulate main content.
<img src="https://cdn.example-domain.com/example2.jpg"/>
</body>
</html>

2. Call the api with the path /parse-html. The API takes a POST with a JSON object containing a URL and HTML. The HMTL is the HTML as provided in step 1 but is first converted to the following format:

<html>\\n<head>\\n<body>\\nMain content\\n<br/>\\n<img src=\"https://cdn.example-domain.com/example1.jpg\"/>\\nMore content\\n<br/>\\nMore Content to Simulate main content.\\n<img src=\"https://cdn.example-domain.com/example2.jpg\"/>\\n</body>\\n</html>\\n

and the URL value that is passed is https://www.example-domain.com

3. The JSON result content being returned contains the main content including the images. The image values are however corrupted:

<img src="https://www.example-domain.com/%22https://cdn.example-domain.com/example1.jpg/%22/">
<img src="https://www.example-domain.com/%22https://cdn.example-domain.com/example2.jpg/%22/">

Question/Comment

Am I using the API in a correct way? I could not find any documentation so this is a bit of reverse engineering.

The reason for not doing this directly, i.e. using the /parser?url=..... is that I am trying to work around a problem where a TypeError is returned. See. The page gives back a 202 which the parser cannot handle. I am now downloading the content and try to pass the HTML into the API as a workaround instead. Unfortunately it doesn't react as I expected it would.

• Platform: AWS Lambda
• Mercury Parser API Version: 0.0.1
• Node Version: v12.11.1

Expected Behavior

API endpoint should allow contentType as text or markdown

Current Behavior

It seems the contentType argument is not present in the code, as the code only takes url and html from the request -

https://github.com/postlight/mercury-parser-api/blob/b6a04af54b3d734e96aa72e487659c087ba09295/src/parse-html.js#L6

Steps to Reproduce

1. Hosted on AWS Lambda as per instructions, can provide link if needed.
2. I just tried to make a GET and POST calls, with the contentType set to text and that doesn't seem to work

Detailed Description

Possible Solution

Code should be updated to accept opts as per Mercury parse - https://github.com/postlight/mercury-parser/blob/b0e708aac6a4e7e10986448a132d60df57c45b00/src/mercury.js#L13

The devDependency serverless was updated from 1.49.0 to 1.50.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

serverless is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴