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

[Deps] [breaking] update cheerio to v1 #1093

Merged
merged 2 commits into from
Sep 5, 2017
Merged

Conversation

ljharb
Copy link
Member

@ljharb ljharb commented Aug 28, 2017

See cheeriojs/cheerio#1047 (comment) for context.

Hoping to merge this ASAP so it can be part of v3.

cc @jugglinmike

This semver range also will include ^1.0.0 once it's released, verified on https://semver.npmjs.com/

@aweary
Copy link
Collaborator

aweary commented Aug 28, 2017

@ljharb test suite seems to be failing

TypeError: _cheerio2.default.load(...)(...).root is not a function

@ljharb
Copy link
Member Author

ljharb commented Aug 28, 2017

Yes, I can't get them running locally yet to fix :-/

@jugglinmike
Copy link

root is a static method on the jQuery-like object produced by load. I guess
the recommendation we made is a little inaccurate. I'll think about how to make
a better explanation for our migration guide.

For your purposes here, could you try exposing simply cheerio.load('')(html)?

@ljharb
Copy link
Member Author

ljharb commented Aug 29, 2017

What's the functional difference? Is the fragment not jquery-like?

What about cheerio(cheerio.load('')(html))?

@jugglinmike
Copy link

Here again, my explanation is more confusing than helpful. "jQuery-like" can
mean a couple things, depending on your interpretation of "jQuery".

The return value of cheerio.load('') could be called "jQuery-like" because it
returns a function that is like the global function defined by jQuery (i.e.
window.$ or window.jQuery). This functions has the static methods defined
by jQuery such as parseHTML, but it also has a Cheerio-specific static method
named root.

The return value of cheerio.load('')('<div>') is "jQuery-like" because it
returns an array-like object whose members are elements (sometimes called a
"jQuery collection").

My apologies for making this more confusing than it needs to be. If it's any
consolation, this conversation is going to help me improve Cheerio's migration
guide, and that will hopefully make the transition easier for others when we do
publish version 1.0. I'd be happy to contribute to this branch and get things
passing, but I may not have any availability until this weekend. Please let me
know!

@ljharb
Copy link
Member Author

ljharb commented Aug 29, 2017

That sounds great; I'll add you to my fork today so you can add to this PR.

.travis.yml Outdated
@@ -3,12 +3,12 @@ node_js:
- "8"
- "6"
- "4"
before_install:
- 'if [ "${TRAVIS_NODE_VERSION}" = "0.6" ]; then npm install -g [email protected] ; elif [ "${TRAVIS_NODE_VERSION}" != "0.9" ]; then case "$(npm --version)" in 1.*) npm install -g [email protected] ;; 2.*) npm install -g npm@2 ;; esac ; fi'
Copy link
Collaborator

Choose a reason for hiding this comment

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

why do we need this and the install script?

Copy link
Member Author

Choose a reason for hiding this comment

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

It ensures npm doesn't break, and deps can be installed on any node version. This will be rebased out tho; only the latest commit on the PR matters.

Copy link
Collaborator

Choose a reason for hiding this comment

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

but we dont use versions of node in travis other than 8, 6 and 4, so why test for 0.6 and 0.4, etc?

Copy link
Member Author

Choose a reason for hiding this comment

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

Because then I can copy paste my known-correct Travis config lines from all my other repos :-)

.travis.yml Outdated
@@ -19,7 +19,7 @@ sudo: false
matrix:
fast_finish: true
include:
- node_js: "6"
- node_js: "node"
Copy link
Collaborator

Choose a reason for hiding this comment

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

why this change?

Copy link
Member Author

Choose a reason for hiding this comment

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

There's no benefit to pinning the linter on node 6.

Copy link
Collaborator

Choose a reason for hiding this comment

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

is there a benefit to pinning the karma tests, seeing as they run in a browser?

Copy link
Member Author

Choose a reason for hiding this comment

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

Only if the karma tools are c deps. I don't know much about karma.

Copy link
Collaborator

Choose a reason for hiding this comment

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

i dont think it makesany difference, but no point in changing it now

The effective breaking change is that now `render` returns a wrapper around the *rendered thing*, like shallow and mount - instead of a “root” that requires you dive into `.children()`

See cheeriojs/cheerio#1047 (comment)
@ljharb ljharb force-pushed the cheerio branch 2 times, most recently from 79f47ee to d6918c4 Compare August 30, 2017 00:56
@ljharb
Copy link
Member Author

ljharb commented Aug 30, 2017

OK, got this working :-)

The effective breaking change is that now render returns a wrapper around the rendered thing, just like shallow and mount will (once v3 is done) - instead of a “root” that requires you dive into .children(). This will make all our APIs more consistent.

@jugglinmike
Copy link

I discovered the same thing last night, but I didn't have the time/imagination
to think of a workaround to preserve Enzyme's current behavior. Even now, I'm
not sure it's possible--that old root "element" was a little like a document
fragment in that it had children but no representation in the rendered DOM.

...so I'm glad that not only is the breaking change acceptable, but that you
find it preferable for consistency's sake!

On the Cheerio side, I plan on updating the migration guide with information
about the root method. We didn't modify its implementation, but now that
we're working with more realistic documents, users should be aware that what
they get back will be different than prior releases (though more in-line with
the browser overall).

Copy link
Collaborator

@nfcampos nfcampos left a comment

Choose a reason for hiding this comment

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

LGTM

@nfcampos
Copy link
Collaborator

@ljharb are we compiling a list of breaking changes for v3?

@ljharb
Copy link
Member Author

ljharb commented Sep 1, 2017

@nfcampos i believe leland has one in progress.

@ljharb ljharb force-pushed the cheerio branch 4 times, most recently from 8339ced to f7c5a15 Compare September 1, 2017 08:07
@ljharb ljharb merged commit 27d05a0 into enzymejs:master Sep 5, 2017
@ljharb ljharb deleted the cheerio branch September 5, 2017 19:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants