Framework: Update/use open interpolate components

[rralian]

This PR switches our i18n process to use the newly-created interpolate-components module, which I've broken out of calypso so it can be used by other projects. The module is published on npm here.

You can run tests separately on the interpolate-components repository itself and they continue to work correctly. All tests are passing in wp-calypso as well, and I've tested calypso in other languages and it's working correctly for me.

One thing I'm unsure of and for which I'd appreciate feedback, is whether interpolate-components should require React (and related modules) as dependencies or peerDependencies. As I understand, using peerDependencies would help us avoid this module having its own separate version of React. But npm 3.0+ doesn't install peerDependencies by default, so that means if you clone interpolate-components, npm install, and then run tests, the tests won't work correctly unless you install those modules manually (which seems lame to me). For now I've left the requires as dependencies (see package.json here). @nb maybe you could weigh in on that?

Testing

There should be no functional changes here. You can clone the other repo and make sure tests are working there if you want. Otherwise just pull down this fork and run tests. Then do some sanity testing across calypso, including checking calypso in different languages.

[ebinnion]

I don't have any comments on the code, and I browsed through Calypso and did not notice any errors. Someone else should probably check this out as well though.

[aduth]

Unrelated to the changes themselves, I wonder if we should start thinking through possible approaches for making packages available on npm without removing them from the Calypso codebase. Another use-case where this could come in handy is in other projects where we might want to re-use UI components from Calypso.

If I'm not mistaken, React and Babel take this sort of approach. All of Babel's packages are contained within the Babel repository, and they use/develop a tool named lerna for managing the publishing of multiple packages to npm.

[aduth]

Also, reasoning for a mono-repo: https://github.com/babel/babel/blob/master/doc/design/monorepo.md

[rralian]

@aduth Thanks, I was blissfully unaware that this is what those other projects were doing, though now that makes sense. I think that would be an excellent way to keep our modules and development in one spot (so easier to manage) and even to help the calypso brand a bit. I'll keep this PR open for now so others can chime in if they have strong opinions, but I'll take a look at lerna. That seems pretty sensible.

[nb]

Do we need to depend on the folder structure of the npm module here? Can we expose tokenize either as part of the main interpolate-components export (interpolateComponents.tokenize()) or as an alternate export (import { tokenize } from 'interpolate-components').

[nb]

The new setup worked well for me, no errors, looks good :)

I left few comments here and there, but nothing is a blocker.

Also, added it to CircleCI: https://circleci.com/gh/Automattic/interpolate-components (you might add the status badge if you feel like it).

I will leave to you and @aduth to decide whether to keep it in the same repo or different ones. Keeping in the same repo makes sense to me, since a lot of my comments were related to things figured out in Calypso.

[dmsnell]

For reference I am adding to the monorepo discussion. We started with this kind of approach in the notifications client, albeit probably not the way it was intended to be done.

Every folder in our tree had its own package.json file and was technically a separate npm module, but they all got build together and lived in the same repo. This eventually became a nightmare with package versions. We used npm-deps to resolve things but it became really hard to build and we ended up with what felt like hundreds of copies of slightly-differently-versioned packages in the node_modules directory. This could have been fixed with newer versions of npm, not sure.

With moderation and proper componentization this could work better than how we had it. For example, this interpolation component is a thing of its own and could live on its own and is pretty bulky; this stands in contrast to doing something like making the <Accordion /> its own module, which probably would lead to the nightmare we faced.

One of the biggest questions I have with this approach and I honestly have no clue on the answer is what implications this has for using the module in other projects. For example, right now in the notifications client we ended up just cloning some files from Calypso for i18n. I would love to rather just import those modules (when they become their own modules) and include that dependency in our package.json. Would I be able to do that easily if it lived inside the Calypso repo and would I have to download the full Calypso repo just to build the i18n modules?

[deBhal]

@dmsnell: Looks like Lerna is a solution for both the problems you mentioned. It's publish command can apply a new version only to packages that have changed since the last git tag. It looks like it even bumps the dependencies in package.json if a package and it's dependency change at the same time (perhaps a little defensive, but seems safe).

Then it npm publishes each sub-package, so they can be require()ed separately in client code. Do we have I don't see anything about the top level package - we probably just tell webpack not to include any of the sub-package stuff.

It makes a lot of assumptions, but it looks like most of them line up pretty nicely (git, npm, SemVer). It needs control over tags to do the conditional version updated (while our latest tag is MERGE_POINT), and it operates on every directory in a directory, but we could modify it if we need to.

Lerna seems cool, I hope we can use it.

[dmsnell]

@deBhal thanks for the info!

[lancewillett]

Closing — see also #3300 (abandoned).