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

Multiple block selection #62

Closed
iseulde opened this Issue Feb 11, 2017 · 23 comments

Comments

Projects
None yet
8 participants
@iseulde
Member

iseulde commented Feb 11, 2017

The user should be able to align/convert a selection over multiple paragraph blocks. I guess this could be solved by having one text block for multiple paragraphs, but how do you then align/convert a single paragraph? I thought it might be nice to be able to select multiple connecting paragraph blocks. Would love to see some discussion around this.

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Feb 14, 2017

Contributor

Really important discussion to have. It also ties directly into #3: what happens when you press ⌘ + A?

Important to keep two things in mind when diving into this:

  1. The goal for the editor:

The editor will endeavour to create a new page and post building experience that makes writing rich posts effortless, and has “blocks” to make it easy what today might take shortcodes, custom HTML, or 'mystery meat' embed discovery.

  1. We'll still have an HTML view somewhere, that doesn't have any blocks.

In a way it could boil right down to the two approaches that have been discussed as worthy of prototyping:

  • In one, TinyMCE is the parent. ⌘ + A selects every block. What UI we show here is going to be a good question, probably worth looking at what desktop layout apps do when you select everything. This speaks to the "inspector" concept that @folletto has come up with.
  • In the other prototype, TinyMCE is a child. When you pres ⌘ + A, you select all the text inside the current block. You have to go into the HTML editor if you want to copy the whole post.
Contributor

jasmussen commented Feb 14, 2017

Really important discussion to have. It also ties directly into #3: what happens when you press ⌘ + A?

Important to keep two things in mind when diving into this:

  1. The goal for the editor:

The editor will endeavour to create a new page and post building experience that makes writing rich posts effortless, and has “blocks” to make it easy what today might take shortcodes, custom HTML, or 'mystery meat' embed discovery.

  1. We'll still have an HTML view somewhere, that doesn't have any blocks.

In a way it could boil right down to the two approaches that have been discussed as worthy of prototyping:

  • In one, TinyMCE is the parent. ⌘ + A selects every block. What UI we show here is going to be a good question, probably worth looking at what desktop layout apps do when you select everything. This speaks to the "inspector" concept that @folletto has come up with.
  • In the other prototype, TinyMCE is a child. When you pres ⌘ + A, you select all the text inside the current block. You have to go into the HTML editor if you want to copy the whole post.
@aduth

This comment has been minimized.

Show comment
Hide comment
@aduth

aduth Feb 20, 2017

Member

I'd shared a demo in Slack which considers treating paragraphs individually, but also as a combined unit when selecting across multiple:

http://codepen.io/aduth/pen/jyRaOp

Member

aduth commented Feb 20, 2017

I'd shared a demo in Slack which considers treating paragraphs individually, but also as a combined unit when selecting across multiple:

http://codepen.io/aduth/pen/jyRaOp

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Feb 21, 2017

Contributor

That works great @aduth !

Contributor

jasmussen commented Feb 21, 2017

That works great @aduth !

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Feb 21, 2017

Contributor

One reason why selecting multiple blocks would be a boon, is when creating longer blockquotes. Say you want to excerpt a document, you might copy/paste that document, select it, then convert it to a blockquote.

Contributor

jasmussen commented Feb 21, 2017

One reason why selecting multiple blocks would be a boon, is when creating longer blockquotes. Say you want to excerpt a document, you might copy/paste that document, select it, then convert it to a blockquote.

@mapk

This comment has been minimized.

Show comment
Hide comment
@mapk

mapk Mar 1, 2017

Contributor

Another take on @aduth's Codepen.

select-multiple

Contributor

mapk commented Mar 1, 2017

Another take on @aduth's Codepen.

select-multiple

@androb

This comment has been minimized.

Show comment
Hide comment
@androb

androb Mar 1, 2017

Contributor

I like that @mapk
The separate blocks feel a bit clumsy.

Contributor

androb commented Mar 1, 2017

I like that @mapk
The separate blocks feel a bit clumsy.

@aduth

This comment has been minimized.

Show comment
Hide comment
@aduth

aduth Mar 1, 2017

Member

It's not illustrated well by the CodePen since the toolbar is static, but it might be problematic to allow selecting across blocks of differing types, which is why my original prototype limited it to adjacent paragraphs only.

  • What block-level controls would I expect to see if I've selected across a heading, paragraphs, and list?
  • What if a block's editable text is non-trivial (i.e. not just a single element like <h2> or <p>)?
    • For example, quotes may need separate contenteditable fields for paragraphs and the citation, or display some markup before/after the editable text.
Member

aduth commented Mar 1, 2017

It's not illustrated well by the CodePen since the toolbar is static, but it might be problematic to allow selecting across blocks of differing types, which is why my original prototype limited it to adjacent paragraphs only.

  • What block-level controls would I expect to see if I've selected across a heading, paragraphs, and list?
  • What if a block's editable text is non-trivial (i.e. not just a single element like <h2> or <p>)?
    • For example, quotes may need separate contenteditable fields for paragraphs and the citation, or display some markup before/after the editable text.
@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Mar 2, 2017

Contributor

These are the right questions to ask @aduth, they are 🔑 to get this right.

What block-level controls would I expect to see if I've selected across a heading, paragraphs, and list?

Blockquote. Incidentally this begs the question: how do you "un-blockquote" a big quote that has lots of nested content? Do blockquotes have a special button in the inline toolbar to remove that formatting?

CC: @mtias & @folletto since their input here would be interesting.

Contributor

jasmussen commented Mar 2, 2017

These are the right questions to ask @aduth, they are 🔑 to get this right.

What block-level controls would I expect to see if I've selected across a heading, paragraphs, and list?

Blockquote. Incidentally this begs the question: how do you "un-blockquote" a big quote that has lots of nested content? Do blockquotes have a special button in the inline toolbar to remove that formatting?

CC: @mtias & @folletto since their input here would be interesting.

@folletto

This comment has been minimized.

Show comment
Hide comment
@folletto

folletto Mar 2, 2017

It's not illustrated well by the CodePen since the toolbar is static, but it might be problematic to allow selecting across blocks of differing types, which is why my original prototype limited it to adjacent paragraphs only.

To find a solution to this it might be useful to think of this in two separate parts:

  1. Selection — the selection should happen on the whole system. It's just natural to be able to select everything, the "blocks" should be transparent to that, regardless of block time.
  2. UI — we then need to decide: what UI should show up, and how blocks that aren't text should show their highlighted status.

I think the prototype above shows a compelling solution, we need to come up with a toolbar / inspector that allows changing in bulk multiple blocks, copy-paste, and deal with "incompatible" blocks. Initially could be as simple as "a block that is incompatible/different is left unchanged if a block change is triggered", and then we can iterate.

Blockquote. Incidentally this begs the question: how do you "un-blockquote" a big quote that has lots of nested content? Do blockquotes have a special button in the inline toolbar to remove that formatting?

Good question. I think it's a matter of how we are treating blockquotes:

  • If it's a block on its own, it can revert to base text by switching to text block, and otherwise can have indentation controls on its toolbar/inspector.
  • If it's treated inside a text block, then indentation can happen with a command in the toolbar, and only when indentation happens, a button to un-indent can appear.
  • It could be a dropdown from "normal" to "indent-level-N": as there's no "lock" in the need of an ident level 2 to be inside an ident level 1 it's less sequential and more like choosing a header: clicking on the icon always raises +1 indent, and to revert there's the dropdown that swaps back to any level instantly.

folletto commented Mar 2, 2017

It's not illustrated well by the CodePen since the toolbar is static, but it might be problematic to allow selecting across blocks of differing types, which is why my original prototype limited it to adjacent paragraphs only.

To find a solution to this it might be useful to think of this in two separate parts:

  1. Selection — the selection should happen on the whole system. It's just natural to be able to select everything, the "blocks" should be transparent to that, regardless of block time.
  2. UI — we then need to decide: what UI should show up, and how blocks that aren't text should show their highlighted status.

I think the prototype above shows a compelling solution, we need to come up with a toolbar / inspector that allows changing in bulk multiple blocks, copy-paste, and deal with "incompatible" blocks. Initially could be as simple as "a block that is incompatible/different is left unchanged if a block change is triggered", and then we can iterate.

Blockquote. Incidentally this begs the question: how do you "un-blockquote" a big quote that has lots of nested content? Do blockquotes have a special button in the inline toolbar to remove that formatting?

Good question. I think it's a matter of how we are treating blockquotes:

  • If it's a block on its own, it can revert to base text by switching to text block, and otherwise can have indentation controls on its toolbar/inspector.
  • If it's treated inside a text block, then indentation can happen with a command in the toolbar, and only when indentation happens, a button to un-indent can appear.
  • It could be a dropdown from "normal" to "indent-level-N": as there's no "lock" in the need of an ident level 2 to be inside an ident level 1 it's less sequential and more like choosing a header: clicking on the icon always raises +1 indent, and to revert there's the dropdown that swaps back to any level instantly.
@joyously

This comment has been minimized.

Show comment
Hide comment
@joyously

joyously Mar 2, 2017

Selection — the selection should happen on the whole system. It's just natural to be able to select everything, the "blocks" should be transparent to that, regardless of block time.

+10 for this. Think of how a user would enclose a selection in a container, so that they can apply styles for the group (like a background color or width or float). They select several existing blocks and choose what to enclose them? Or create the container block and move other blocks into it, singly or as a group?

joyously commented Mar 2, 2017

Selection — the selection should happen on the whole system. It's just natural to be able to select everything, the "blocks" should be transparent to that, regardless of block time.

+10 for this. Think of how a user would enclose a selection in a container, so that they can apply styles for the group (like a background color or width or float). They select several existing blocks and choose what to enclose them? Or create the container block and move other blocks into it, singly or as a group?

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Mar 29, 2017

Contributor

Here's a pretty neat prototype by Ella for selecting across blocks in the multi-instance approach: https://codepen.io/iseulde/full/bqmwvb/

Contributor

jasmussen commented Mar 29, 2017

Here's a pretty neat prototype by Ella for selecting across blocks in the multi-instance approach: https://codepen.io/iseulde/full/bqmwvb/

@iseulde

This comment has been minimized.

Show comment
Hide comment
@iseulde

iseulde Mar 29, 2017

Member

Even though it doesn't seem to be one of the initial requirements for this plugin, I think it's important to get this figured out as soon as possible. Only being able to select inside block boundaries is bit awkward and it feels limiting.

When people select across blocks in the current editor, what do they want to do with this selection? It seems that in most cases this is: copy/paste (internal or external), move with the arrows, delete and applying formatting on the selected blocks (wrap in quote, align...)

These seem to be mostly block level interactions, so might it make sense to switch to block level selection as soon as you cross the block boundary?

One other use case is deleting and merging part of two or more pieces of text at once. You'd have to delete the pieces and merge separately (3+ steps). Any other use cases that this solution doesn't solve?

Member

iseulde commented Mar 29, 2017

Even though it doesn't seem to be one of the initial requirements for this plugin, I think it's important to get this figured out as soon as possible. Only being able to select inside block boundaries is bit awkward and it feels limiting.

When people select across blocks in the current editor, what do they want to do with this selection? It seems that in most cases this is: copy/paste (internal or external), move with the arrows, delete and applying formatting on the selected blocks (wrap in quote, align...)

These seem to be mostly block level interactions, so might it make sense to switch to block level selection as soon as you cross the block boundary?

One other use case is deleting and merging part of two or more pieces of text at once. You'd have to delete the pieces and merge separately (3+ steps). Any other use cases that this solution doesn't solve?

@iseulde

This comment has been minimized.

Show comment
Hide comment
@iseulde

iseulde Mar 29, 2017

Member

Just in case you can't try the demo:

There are three editable areas (so much like text areas). You can select text inside the area normally.

screenshot 2017-03-29 09 55 07

As soon as you move the mouse outside this area, you're selecting blocks instead of just text. If you copy, the blocks will be copied as a whole.

screenshot 2017-03-29 09 55 35

Member

iseulde commented Mar 29, 2017

Just in case you can't try the demo:

There are three editable areas (so much like text areas). You can select text inside the area normally.

screenshot 2017-03-29 09 55 07

As soon as you move the mouse outside this area, you're selecting blocks instead of just text. If you copy, the blocks will be copied as a whole.

screenshot 2017-03-29 09 55 35

@iseulde

This comment has been minimized.

Show comment
Hide comment
@iseulde

iseulde Mar 29, 2017

Member

Another thing we could try is having a global contenteditable and the non editable blocks outside of it (which can have smaller editable fields). This could work by having anchors in the main editor that hold the space for the non editable block. Selection in the main editor would just work as normal, and the placeholders can contain the HTML that should be copied. Another cool thing is that you can move blocks around without actually moving the node in the DOM, so iframes wouldn't refresh. One big downside is that you'd have to keep the dimensions is sync...

Member

iseulde commented Mar 29, 2017

Another thing we could try is having a global contenteditable and the non editable blocks outside of it (which can have smaller editable fields). This could work by having anchors in the main editor that hold the space for the non editable block. Selection in the main editor would just work as normal, and the placeholders can contain the HTML that should be copied. Another cool thing is that you can move blocks around without actually moving the node in the DOM, so iframes wouldn't refresh. One big downside is that you'd have to keep the dimensions is sync...

@androb

This comment has been minimized.

Show comment
Hide comment
@androb

androb Mar 29, 2017

Contributor

Interesting idea @iseulde

@intronic how does this approach compare/complement with what you were looking at with the tinymce-single-react-ui prototype?

And with your thoughts around a block API @spocke and @Afraithe ?

Contributor

androb commented Mar 29, 2017

Interesting idea @iseulde

@intronic how does this approach compare/complement with what you were looking at with the tinymce-single-react-ui prototype?

And with your thoughts around a block API @spocke and @Afraithe ?

@Afraithe

This comment has been minimized.

Show comment
Hide comment
@Afraithe

Afraithe Mar 29, 2017

Not sure our block api serves any purpose in a multi instance tinymce setting. In single tinymce, selection isn't really much of an issue and handled. I think we view blocks a bit differently here.

Afraithe commented Mar 29, 2017

Not sure our block api serves any purpose in a multi instance tinymce setting. In single tinymce, selection isn't really much of an issue and handled. I think we view blocks a bit differently here.

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen Apr 26, 2017

Contributor

As an update on this, we are exploring two approaches for this in #513, of which one of them addresses some of the concerns.

Contributor

jasmussen commented Apr 26, 2017

As an update on this, we are exploring two approaches for this in #513, of which one of them addresses some of the concerns.

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen May 5, 2017

Contributor

In master we have a continuous text block, and you can split it into individual paragraph blocks if you like, with double enter. You can merge them right back again with backspace. This is working well. As such, I'm going to close this as addressed for now.

If during a dogfooding period we find that this is still not fully addressed, we can always reopen this!

Contributor

jasmussen commented May 5, 2017

In master we have a continuous text block, and you can split it into individual paragraph blocks if you like, with double enter. You can merge them right back again with backspace. This is working well. As such, I'm going to close this as addressed for now.

If during a dogfooding period we find that this is still not fully addressed, we can always reopen this!

@jasmussen jasmussen closed this May 5, 2017

@iseulde

This comment has been minimized.

Show comment
Hide comment
@iseulde

iseulde May 5, 2017

Member

Hm, I'm not sure what these two have in common?

Member

iseulde commented May 5, 2017

Hm, I'm not sure what these two have in common?

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen May 5, 2017

Contributor

Oh I'm sorry, got over eager there, and misread the use case as merging blocks.

Contributor

jasmussen commented May 5, 2017

Oh I'm sorry, got over eager there, and misread the use case as merging blocks.

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen May 24, 2017

Contributor

We are in a good place with many of the blocks now, so it feels like time to revisit this!

Here's a fresh mockup:

selecting across blocks

When you drag outside the boundaries of a block, you start selecting the blocks. The purpose is solely to allow you to delete multiple blocks, or to move multiple blocks.

Contributor

jasmussen commented May 24, 2017

We are in a good place with many of the blocks now, so it feels like time to revisit this!

Here's a fresh mockup:

selecting across blocks

When you drag outside the boundaries of a block, you start selecting the blocks. The purpose is solely to allow you to delete multiple blocks, or to move multiple blocks.

@iseulde

This comment has been minimized.

Show comment
Hide comment
@iseulde

iseulde May 24, 2017

Member

Looking good :)

Member

iseulde commented May 24, 2017

Looking good :)

@jasmussen

This comment has been minimized.

Show comment
Hide comment
@jasmussen

jasmussen May 31, 2017

Contributor

This is in! Closing this ticket in favor of #950, and #951.

Contributor

jasmussen commented May 31, 2017

This is in! Closing this ticket in favor of #950, and #951.

@jasmussen jasmussen closed this May 31, 2017

omarreiss pushed a commit that referenced this issue Jun 26, 2018

Scripts: New scripts package containing test command (#62)
* Scripts: initial commit with scripts package containing test command

* Publish

 - @wordpress/scripts@1.0.1-0

* Scripts: Minor changes before publishing to npm

gziolo added a commit that referenced this issue Jul 9, 2018

Packages: Move packages repository into Gutenberg (#7556)
* camelCase for readme variable names

* update hook and `vendor/plugin/function` wording, removing `Name`

* complte namespace shortening to `vendor/plugin/function`

* Publish

 - @wordpress/a11y@0.1.0-beta.2
 - @wordpress/dom-ready@0.1.0-beta.2
 - @wordpress/hooks@0.1.0-beta.0
 - @wordpress/url@0.1.0-beta.2

* add publishConfig->access:public for hooks

* Publish

 - @wordpress/hooks@0.1.0-beta.1

* correctly enable dashes in regexes in validateNamespace

* Export a hooks function enabling adding hooks via composition

* test hooks can be instantiated

* Run test on objects instead of globally

* correct data return for Hooks

* Rework the Hooks object, use a local HOOKS instead of global

* use object based hooks throughout testing

* remove unused global HOOKS

* remove some logging

* remove extra parts from namespace in tests

* remov vendor/plugin prefix requirement for namespaces

* update docs

* Add a test for “Can add filters with dashes in namespaces”

* a11y: Apply .screen-reader-text styles to container

* a11y: Update tests per updated style

Questionable value of the test assertions, which are specific to the implementation and not the expected intent of the test case

* update readme, add some tests

* switch naming to `createHooks` and correct tests

* remove extraneous single quotes

* remove the HOOKS global abstraction

* update test beforeEach cleanup to match new object structure

* use export defaults

* Clean up readme for new approach

* url - add built files

* hooks - add built files

* dom-ready - add built files

* a11y - add built files

* remove build filders from gitignore

* Publish

 - @wordpress/a11y@0.1.0-beta.3
 - @wordpress/dom-ready@0.1.0-beta.3
 - @wordpress/hooks@0.1.0-beta.2
 - @wordpress/url@0.1.0-beta.3

* re-ignore build files; didn’t resolve publishing issue

* Simplify dom-ready package.json, add a license field

* Publish

 - @wordpress/a11y@0.1.0-beta.4
 - @wordpress/dom-ready@0.1.0-beta.4
 - @wordpress/hooks@0.1.0-beta.3

* Update readmes to include `@next` in npm install line

Since our packages are still in pre-release, the @next tag is required to install the latest published version. We can remove this instruction once the packages are past pre-release.

* Publish

 - @wordpress/a11y@0.1.0-beta.5
 - @wordpress/dom-ready@0.1.0-beta.5
 - @wordpress/hooks@0.1.0-beta.4
 - @wordpress/url@0.1.0-beta.4

* remove the built files which were added by mistake

* Publish

 - @wordpress/a11y@0.1.0-beta.6
 - @wordpress/dom-ready@0.1.0-beta.6
 - @wordpress/hooks@0.1.0-beta.5
 - @wordpress/url@0.1.0-beta.5

* Hooks: Update hooks public API to make it possible to apply to wp.hooks directly (#45)

* Development: Improve onboarding experience for new contributors (#46)

* Update screen-reader-text CSS.

* Hooks: Allow slashes in the namespace (#47)

* Hooks: Allow slashes in the namespace

* Hooks: Add test ensuring backlash is not allowed inside namespace

* Publish

 - @wordpress/a11y@1.0.0
 - @wordpress/hooks@1.0.0

* a11y & hooks: remove ‘@next’ from install instructions

* tag a11y and hooks at 1.0.1

* Trigger actions when adding or removing hooks

* add tests for expected hookAdded and hookRemoved events

* these are hooks not hoods (typo)

* Tests: Refactor tests to use Jest mocks

* Standardize format of package.json files (#54)

* Add tests for addFilter/removeFilter

* whitespace

* Docs update for hooks added/removed events

* Hooks: Final touches for the add/remove actions

* Publish

 - @wordpress/a11y@1.0.2
 - @wordpress/dom-ready@0.1.0-beta.7
 - @wordpress/hooks@1.1.0
 - @wordpress/url@0.1.0-beta.6

* Update Lerna and Jest to the latest version (#56)

* Implement autop package

* Port PHP wpautop faithfully to JS

* docs: Update Lerna docs to use `npx`

* Update license in `package.json` to adhere to SPDX v3.0 specification

* Update license in `package.json` to adhere to SPDX v3.0 specification

* Enforce using the latest LTS version (8.x) of Node and up

* Move node version check to prebuild run script

* Remove superfluous `a` and use full Node.js name

* Jest-console: Add new package with console object matchers for Jest

* Jest-console: Add package documentation

* Jest-console: Integrate test matchers with packages repository

* Jest-console: Fix typos in README file

* Jest-console: Whitelist folders published to npm

* Update install instruction in README files that use beta releases (#63)

* Publish

 - @wordpress/a11y@1.0.3
 - @wordpress/autop@1.0.1
 - @wordpress/dom-ready@1.0.0
 - @wordpress/hooks@1.1.1
 - @wordpress/jest-console@1.0.0
 - @wordpress/url@1.0.0

* chore: Update `.editorconfig` to match WordPress' upstream

* chore: Use tabs for indentaion in `lerna.json`

* chore: Use tabs for indentaion in _root_ `package.json` and `package-lock.json` files

* chore: Use tabs for indentaion in _url_ package `package.json` and `package-lock.json` files

* chore: Use tabs for indentaion in _jest-console_ package `package.json` and `package-lock.json` files

* chore: Use tabs for indentaion in _hooks_ package `package.json` and add missing `package-lock.json` file

* chore: Use tabs for indentaion in _dom-ready_ package `package.json` and `package-lock.json` files

* chore: Use tabs for indentaion in _autop_ package `package.json` and `package-lock.json` files

* chore: Use tabs for indentaion in _a11y_ package `package.json` and `package-lock.json` files

* chore: Update _autop_ `package.json` fields

* Babel-preset-default: Add new package containing the default Babel configuration (#66)

* Publish (#67)

- @wordpress/a11y@1.0.4
 - @wordpress/autop@1.0.2
 - @wordpress/babel-preset-default@1.0.1-0
 - @wordpress/dom-ready@1.0.1
 - @wordpress/hooks@1.1.2
 - @wordpress/jest-console@1.0.1
 - @wordpress/url@1.0.1

* Scripts: New scripts package containing test command (#62)

* Scripts: initial commit with scripts package containing test command

* Publish

 - @wordpress/scripts@1.0.1-0

* Scripts: Minor changes before publishing to npm

* Publish

 - @wordpress/a11y@1.0.5
 - @wordpress/autop@1.0.3
 - @wordpress/babel-preset-default@1.0.0
 - @wordpress/dom-ready@1.0.2
 - @wordpress/hooks@1.1.3
 - @wordpress/jest-console@1.0.2
 - @wordpress/scripts@1.0.0
 - @wordpress/url@1.0.2

* feat: Add `@wordpress/browserslist-config` package

* docs: fix spelling in CHANGELOG.md and consistent formatting

* chore: remove `browserslist` from `peerDependencies`

* tests(browserslist-config): refactor test per coding standards

* Packages: Make sure dependencies are properly exposed for external usage (#71)

* Publish

 - @wordpress/babel-preset-default@1.0.1
 - @wordpress/browserslist-config@2.0.0
 - @wordpress/jest-console@1.0.3
 - @wordpress/scripts@1.0.1

* Babel-preset-default: Makre sure transform runtime plugin is not loaded in test env (#73)

* Publish

 - @wordpress/babel-preset-default@1.0.2

* 📦 NEW: Update Lerna to 2.8.0

* chore: use tabs for indentation in `lerna.json`

* build: use `browserslist-config-wordpress` Browserslist shared config (#68)

* build: use `browserslist-config-wordpress` Browserslist shared config

* chore(babel-preset-default): switch to `@wordpress/browserslist-config`

* chore: fix merge conflict

* chore: regenerate `package-lock.json`

* Browserslit config: Add devDependency in the root repository

* Babel preset default: Add missing spaces around square brackets

* Jest preset: Add default jest preset for WordPress development (#74)

* Jest preset: Add default jest preset for WordPress developmnent

* Jest preset: Use path to jest preset relative to root directory

* Publish

 - @wordpress/babel-preset-default@1.0.3
 - @wordpress/jest-preset-default@1.0.0
 - @wordpress/scripts@1.0.2

* Tests: Fix wrongly configured dependencies for Jest preset (#75)

* Publish

 - @wordpress/jest-preset-default@1.0.1

* Dependencies: Update Jest preset dependencies version (#76)

* Build: Symlink all child packages instead of using versions published to npm (#77)

* docs: add link to browserslist usage examples docs (#80)

* docs: update browserslist readme example usage

* docs (browserslist): Link to external configuration examples

* Update README.md

* chore(browserslist): update Browserslist to v3.0.0

* chore(browserslist): update Browserslist to v3.1.0

* Publish

 - @wordpress/babel-preset-default@1.1.0
 - @wordpress/browserslist-config@2.1.0
 - @wordpress/jest-console@1.0.4
 - @wordpress/jest-preset-default@1.0.2

* chore: update Lerna to 2.9.0

* Build: Use node script to symlink local npm dependencies (#79)

* Build: Use node script to symlink local npm dependencies

* Chore: Update symlink-or-copy to v1.2.0

* Chore: Added npm-run-all to simplify npm scripts

* docs: ❤️  Code is Poetry

* docs: use canonical _Code is Poetry_ image and center image using HTML

Props @rmccue.

* Scripts: Provide the default configuration for the `test` command (#83)

* Scripts: Provide the default configuration for the `test` command
It is used in the case when the project does not have a config for Jest or Babel

* Scripts: Add tests for utils to ensure they work properly

* Add back end-of-file new line

* fix(scripts): rename script from `test-unit` to `test-unit-js` (#86)

* Chore: Update Jest dependencies (#87)

* Publish

 - @wordpress/a11y@1.0.6
 - @wordpress/autop@1.0.4
 - @wordpress/babel-preset-default@1.1.1
 - @wordpress/browserslist-config@2.1.1
 - @wordpress/dom-ready@1.0.3
 - @wordpress/hooks@1.1.4
 - @wordpress/jest-console@1.0.5
 - @wordpress/jest-preset-default@1.0.3
 - @wordpress/scripts@1.1.0
 - @wordpress/url@1.0.3

* chore: remove `package-lock.json` files, lockfiles for apps, but not for packages

* chore: add `package-lock.json` to `gitignore`

* chore: add `package-lock=false` in new `.npmrc` files for each package

* chore: add `"npmClientArgs": ["--no-package-lock"]` to Lerna `bootstrap` command

See lerna/lerna#1235 (comment)

* Remove Lerna `npmClientArgs` option

* Hooks: Avoid validating namespace in runHooks

Unnecessary because a hook cannot be registered with an invalid hook name, so it would not pass the subsequent condition to check that a hookset with corresponding name exists.

* Hooks: Use null prototype object with truthy access

https://jsperf.com/object-create-null-vs-hasownproperty

* Hooks: Simplify return first arg logic

Even if we don't intend to return value, no harm in assigning to args[ 0 ]

* Hooks: Assign hooks current initial value in creation

* Hooks: Avoid initializing hook history if not run

* Hooks: Add baseline benchmark

* Publish

 - @wordpress/a11y@1.0.7
 - @wordpress/autop@1.0.5
 - @wordpress/babel-preset-default@1.1.2
 - @wordpress/browserslist-config@2.1.2
 - @wordpress/dom-ready@1.0.4
 - @wordpress/hooks@1.1.5
 - @wordpress/jest-console@1.0.6
 - @wordpress/jest-preset-default@1.0.4
 - @wordpress/scripts@1.1.1
 - @wordpress/url@1.0.4

* Wrap filename in backticks

* Package: Add `@wordpress/custom-templated-path-webpack-plugin` package

* chore: add` jest-preset` keyword to `jest-preset-default`

* Hooks: Fix undefined arguments on consecutive action callbacks

* Hooks: Correct CHANGELOG version to 1.1.6

* Publish

 - @wordpress/hooks@1.1.6
 - @wordpress/jest-preset-default@1.0.5
 - @wordpress/scripts@1.1.2

* Custom Templated Path Plugin: Remove debugging statement from tests

😬

* docs: updated handbook URL

* docs: update the Browserslist example repo URL (#98)

* WordPress i18n package: Initial commit (#96)

* docs(i18n): Standardize `README.md` format

* Publish

 - @wordpress/babel-plugin-makepot@1.0.0
 - @wordpress/babel-preset-default@1.1.3
 - @wordpress/browserslist-config@2.1.3
 - @wordpress/custom-templated-path-webpack-plugin@1.0.1
 - @wordpress/i18n@1.0.0
 - @wordpress/scripts@1.1.3

* return a boolean from `hasHook` not the hook count

* simplify logic

* update tests to expect booleans from hasFilter/Action

* Clean up docs and return

* Add `publish:check` script to run `lerna updated`

* babel-preset-default: Remove babel-plugin-lodash (#109)

* Publish

 - @wordpress/babel-preset-default@1.2.0
 - @wordpress/hooks@1.1.7
 - @wordpress/scripts@1.1.4

* i18n: Support accumulatively registering additional locale data for domain (#105)

* allow for setting additional locale data for a domain accumulatively

* woops wrong object reference

* add test for accumulation of localeData

* repackage additional tests

* use more performant “in” check instead of lodash `_.has`

* use hasOwnProperty instead of in

* fix formatting for code style

* fix formatting

* use Object.assign instead of lodash.merge

* add new plural strings to tests

* simplify merging

* indent, indent

* i18n: Fix indentation

* i18n: Memoize dcnpgettext (#101)

* i18n: Memoize dcnpgettext

* i18n: Export dcnpgettext inline

* Publish

 - @wordpress/i18n@1.1.0

* Add WordCounter package (#10)

* Adding WordCounter package

* Simplifying test syntax

* export the count as default

* Creating a simpler API

* Refactor into a single function export

*  Modification based on review notes

* Complete refactor based on suggestions from @omarreiss

* Remove conditional check

* Moving each function into a new file. Exporting an object so we can use a single settings property and make the calls a little more sane

* Only importing the lodash method we need

* Using flow to chain the matchWords/matchCharacters inner function calls

* Adding readme

* Addressing some feedback on the PR

* Move to a simplier API

* Updates the README to match API changes

* Updates per review by @youknowriad

* Adds missing dockblock param

* Spacing issues

* Adds correct docblocks and fixes some whitespace issues

* Adding some whitespace as per review comment

* Add prependHTTP() to @wordpress/url (#112)

* Publish

 - @wordpress/url@1.1.0
 - @wordpress/wordcount@1.0.0

* Add a publishConfig setting to wordcount's package.json, and fix the indenting. (#114)

* Improve the publishing process documentation and error checking (#115)

* Add package: @wordpress/is-shallow-equal (#110)

* Add package: @wordpress/is-shallow-equal

* Ignore benchmark for codecov

No need to affect the codecoverage stats with a benchmarking script

* Define benchmark dependencies as devDependencies

Otherwise considered a proper required dependency from perspective of consuming project

* Add test for arrays being completely equal (#117)

* Add test for arrays being completely equal

It's a nearly useless test, but it does get is-shallow-equal to 100% test coverage
See https://codecov.io/gh/WordPress/packages/src/master/packages/is-shallow-equal/index.js#L48 for the one piece of code not currently tested.

* fix spacing

* add test for object copies

* is-shallow-equal: Fall back to strict equality for non-object-like (#116)

* Ensure inverse argument order has same test result

* is-shallow-equal: Fall back to strict equality for non-object-like

* is-shallow-equal: De-snark README.md

* is-shallow-equal: Add changelog entry for 1.0.1

* wordcount: Add changelog entry for 1.0.1

* Publish

 - @wordpress/is-shallow-equal@1.0.1
 - @wordpress/wordcount@1.0.1

* Improve hooks docs (#121)

* Add a missing `p` in the docs remove -> removep (#120)

* Fix/wordcount whitespace only error (#123)

* Addresses error thrown when the results of matchWord or matchCharacters returns null. Includes test for the case

* Changes as per @tofumatt

* Going full ternary

* is-shallow-equal: Use implicit index.js for main entry (#124)

* Add autop@1.0.5 CHANGELOG entry

* Add hooks@1.1.7 CHANGELOG entry

* Add is-shallow-equal@1.0.2 CHANGELOG entry

* Add wordcount@1.0.2 CHANGELOG entry

* Correct autop, hooks latest CHANGELOG versions

* Publish

 - @wordpress/autop@1.0.6
 - @wordpress/hooks@1.1.8
 - @wordpress/is-shallow-equal@1.0.2
 - @wordpress/wordcount@1.0.2

* Add `@wordpress/npm-package-json-lint-config` package (#119)

* Add `@wordpress/npm-package-json-lint-config` package

* Standardize packages `package.json` format per `@wordpress/npm-package-json-lint`

* Add unused `npm-package-json-lint` rules for reference

* Update `npm-package-json-lint` to `3.0.0-alpha3`

* Add `valid-values-publishConfig` rule with `{"access": "public"}` option for _packages_ repo

* use tabs for indentation

* Update npm-package-json-lint to v3

* Update npmPackageJsonLintConfig config formatting

* Use latest `3.0.1` npm-package-json-lint release and remove `.npmpackagejsonlintrc.json`

* Use `lint:pkg-json` as the npmPkgJsonLint script task name

* fix `pretest` test script command

* Npm package.json lint config: address my own comments

* Add is-plain-object as devDependency

* Add wordcount@1.0.3 CHANGELOG entry

* Add scripts@1.1.5 CHANGELOG entry

* Add npm-package-json-lint-config@1.0.0 CHANGELOG entry

* Add jest-preset-default@1.0.5 CHANGELOG entry

* Add jest-console@1.0.6 CHANGELOG entry

* Add i18n@1.1.1 CHANGELOG entry

* Add custom-templated-path-webpack-plugin@1.0.2 CHANGELOG entry

* Add browserslist-config@2.1.3 CHANGELOG entry

* Add babel-preset-default@1.2.1 CHANGELOG entry

* Add babel-plugin-makepot@1.0.1 CHANGELOG entry

* Add browserslist-config@2.1.4 CHANGELOG entry

* Add jest-preset-default@1.0.6 CHANGELOG entry

* Add jest-console@1.0.7 CHANGELOG entry

* Add a custom Lerna publish commit message (#125)

* chore(release): publish

 - @wordpress/babel-plugin-makepot@1.0.1
 - @wordpress/babel-preset-default@1.2.1
 - @wordpress/browserslist-config@2.1.4
 - @wordpress/custom-templated-path-webpack-plugin@1.0.2
 - @wordpress/i18n@1.1.1
 - @wordpress/jest-console@1.0.7
 - @wordpress/jest-preset-default@1.0.6
 - @wordpress/npm-package-json-lint-config@1.0.0
 - @wordpress/scripts@1.1.5
 - @wordpress/wordcount@1.0.3

* Babel preset: Enable support for async generator functions (#126)

* Babel preset: Enabled support for async generator functions

* Babel preset: Add unit tests for async generator functions

* Babel preset: Update changelog

* chore(release): publish

 - @wordpress/babel-preset-default@1.3.0
 - @wordpress/scripts@1.1.6

* chore: update `codecov` to v3, resolves all `npm audit` issues. (#127)

* Scripts: Add support for lint-pkg-json script (#128)

* Scripts: Add support for lint-pkg-json script

* Scripts: Update documentation for `lint-pkg-json` command

* Scripts: Update changelog

* chore(release): publish

 - @wordpress/scripts@1.2.0

* Count when a hook that doesn't have any handlers is run. (#134)

Fixes #133.

* chore(release): publish

 - @wordpress/hooks@1.2.0

* Jest Console: Add new matchers for console.log and console.info (#137)

* Jest Console: Add new matchers for console.log and console.info

* Jest-console: Update CHANGELOG with braking changes details

* Move packages from temporary directory to packages/

* Remove all the obsolete files from the old packages

* Synchronize package.json with the one from packages.

* Synchronize lerna.json with the one from packages

* Remove old packages build script

* Add `is-shallow-equal/benchmark` to codecov ignore

* Remove npm-run-all

* Packages: Synchronize dependencie to avoid having copies of the same libraries

* Tests: Update test config to work with local packages

* ESLint initial fixes via --fix

* Build: Make Webpack build work again :)

* Build: Fix the issue with babel makepot plugin

* Packages: Fix all linter errors

* Build: Use Lerna 3 for managing packages

It folows the setup of Lerna itself which demonstrates "the golden path of local file: specifiers at scale".
See: lerna/lerna#1307.

* Packages: Fix configuration with newly introduced packages

* Testing: Try to fix jest-console tests

* Testing: Try to fix jest-console tests

* jest-preset-default: Alphabetize dependencies

* Testing: Use toThrowError matcher for jest-console
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment