v1.0.0 #1145
v1.0.0 #1145
Conversation
|
This is great! Thanks for taking the lead here. One thing from Matt's original issue about 1.0 that I liked was a formalization of the API documentation. I did some work toward this end in the fall of last year, but I never submitted it for review because JSDoc (the documentation generator I selected) is missing a feature that is crucial for the Cheerio API. While I think it would be nice to have a solid website available with the announcement of version 1.0, that is far less important than the technical improvements that we want to publish. I'm really pleased that you're taking initiative on this, and I don't want to get in the way. I'm thinking that there is still value in the consistent use of JSDoc over our current solution (where usage information is split between the source code and the overlong If you agree, then I can rebase those changes and remove the build process. What do you think? |
fb55
force-pushed
the
v1.0.0
branch
2 times, most recently
from
5dd00be
to
f86985f
Compare
Update test phrasing according to recent changes in parsing logic.
Limit responsibility of "pre-publish" script to simply validate the project's `History.md` file (by verifying an entry for the current release). Define a separate script for history generation. Separating the workflow in this way allows for manual modification of the release notes.
Simply expose an option named `xml` that enables XML parsing via htmlparser2 with the ability to specify additional options for that parser.
This flag is used to control parsing behavior internally, but it is not intended for use by consumers. Prefix the name with an underscore in order to discourage users from relying on it.
Incorporate recent feedback from consumers who have experimented with the version 1.0 release candidate.
Breaking change: Invalid selectors now throw Errors, not SyntaxErrors.
Since enabling the `withDomLvl1` parsing option, nodes cannot be created with an object literal. Create new text nodes using the `evaluate` function to ensure they expose the correct attributes.
… case to the switch in the prop function, which wraps a clone of in a container element, and sets to that container's HTML (#945)
This includes code coverage reports as generated by the command `make test-cov`.
* Correct typo in git hook configuration * Reformat package manifest to satisfy linter
|
Opened PRs for all the changes I wanted to make. Once these are merged we might want to write an accompanying post somewhere (eg. Medium) basically outlining what changed and do a big release :D |
|
@jugglinmike Adding jsdoc is still super valuable, and not something we should skip just because we can't model one relationship. We could also use something like https://github.com/bradtaylorsf/markdown-magic-jsdoc as a very simple way to generate markdown from jsdoc comments. |
|
One thing I would like to avoid is checking generated assets into the main development branch. That practice causes confusion for new contributors and also adds noise to the commit history. But your point about the value of the change and the relative unimportance of the issue is well-taken. I think this is a case where I've gotten too hung up on a small detail. Thanks for making that more clear! I've rebased that documentation branch and submitted it at gh-1165. Looking forward to writing that blog post :) |
We should figure out a way to automate generation of docs then. Having them in the main branch would make it easy, as Github pages would just pick them up (and we could link to it). We could even add a precommit hook that automatically generates docs whenever you commit. One alternative would be something like Netlify, which could pull the master branch automatically.
You are definitely the one deserving most of the credit here, happy to proof-read drafts or help in any other way! |
There are a couple downsides to using githooks to synchronize redundant documentation files on the
How about publishing docs to a dedicated branch instead? We can push to that branch at any moment, using whatever branch ( |
I like that approach, happy to go forward with it! Sorry for taking a bit :/ |
Promote consistency in variable names within the project's source and unit tests. This helps to highlight the distinction between the object exported by the module and the function produced by the `load` method. The latter value is expected to mimic the jQuery API, while the former value generally should only be used for a small set of methods specific to Cheerio: - `load` - `html` - `xml` - `text` Other usages of the exported object are discouraged, and a future patch will update the unit tests to reflect the usages that are endorsed for long-term stability.
Methods named `load`, `html`, `xml`, and `text` are defined in many locations: Today, Cheerio defines multiple versions of methods named `load`, `html`, `xml`, `text`, and `parseHTML`. These alternate versions may be defined in up to three distinct parts of the API: - exported by the Cheerio module - as static methods of the "loaded" Cheerio factory function - as instance methods of the "loaded" Cheerio factory function Some of these are surperfluous, and because some unecessarily conflict with idiomatic jQuery coding patterns, they have been designated for future removal [1]. Add tests for the deprecated methods in order to avoid regressions prior to their removal. Insert comments to delineate the methods which are endorsed and which have been deprecated. For the latter group of methods, include recommendation for the preferred alternatives. [1] #1122
* Implement for...of iterator via Symbol.iterator Similar to jQuery: https://github.com/jquery/jquery/blob/1ea092a54b00aa4d902f4e22ada3854d195d4a18/src/core.js#L371-L373 Fixes #1191 * Assert that the iterator ends #1197 (comment)
Is the this PR safe to use other than #1050? |
|
Merging this to master to push us to get this out eventually. I've created a project that allows us to track progress. |
This reverts commit ca6963c. The `v1.0.0` branch was a long-running feature branch containing a large amount of disparate commits from many authors. It was squashed into a single commit prior to being merged to the project's `master` branch. For the purposes of attribution, reference, and history analysis, the composit commits should be preserved, and the branch should be incorporated into `master` via a dedicated merge commit.
This reverts commit ca6963c. The `v1.0.0` branch was a long-running feature branch containing a large amount of disparate commits from many authors. It was squashed into a single commit prior to being merged to the project's `master` branch. For the purposes of attribution, reference, and history analysis, the composite commits should be preserved, and the branch should be incorporated into `master` via a dedicated merge commit.
|
Glad to see some movement here, but I think the context of this branch make Separately: I agree that we should get moving on this, but I'd rather not merge |
This reverts commit ca6963c. The `v1.0.0` branch was a long-running feature branch containing a large amount of disparate commits from many authors. It was squashed into a single commit prior to being merged to the project's `master` branch. For the purposes of attribution, reference, and history analysis, the composite commits should be preserved, and the branch should be incorporated into `master` via a dedicated merge commit.
Wanted to open this to track remaining work and get the final 1.0.0 release going.
Should be resolved:
xlink:hreftohref#1101 (potentially switch serialisers?) — PR open as Use parse5 to serialise the DOM, use lodash to clone dom #1164Other improvements:
Closes #1047, #985
@jugglinmike Anything else you can think of? I should have sufficient availability next week, happy to look into this.