Mass migration from package-relative imports to wp-calypso-client

[scinos]

Background

See #44602

Changes

• Enable rule wpcalypso/no-package-relative-imports in ./eslintrc.js
• Allow imports from parent node_modules. This is not ideal, but afaik is the only way to tell eslint that importing from calypso/... is fine.
• Apply auto-fix for the rule wpcalypso/no-package-relative-imports in ./client/me/**/*
• Run prettier in the affected files

After this PR is merged, wpcalypso/no-package-relative-imports becomes like any other eslint rule in our repo: there are many files that violate that rule, and as soon as a developer change one of those files, eslint will complain and they will have to migrate it.

Meanwhile I'll continue creating PRs with auto-fixer applied in batch to some folders to reduce the violations of this rule.

Testing instructions

• Check all tests passes (ignore lint errors, there will be a ton).
• Do a smoke test on the live branch
• Verify there are no huge changes in package size in ICFY report.

[matticbot]

Test live: https://calypso.live/?branch=fix/migrate-to-wp-calypso-client

[matticbot]

Here is how your PR affects size of JS and CSS bundles shipped to the user's browser:

Webpack Runtime (~52 bytes added 📈 [gzipped])

name      parsed_size           gzip_size
manifest       +194 B  (+0.3%)      +52 B  (+0.3%)

Webpack runtime for loading modules. It is included in the HTML page as an inline script. Is downloaded and parsed every time the app is loaded.

App Entrypoints (~28 bytes added 📈 [gzipped])

name                   parsed_size           gzip_size
entry-main                   +59 B  (+0.0%)       +7 B  (+0.0%)
entry-login                  +59 B  (+0.0%)       +7 B  (+0.0%)
entry-gutenboarding          +59 B  (+0.0%)       +7 B  (+0.0%)
entry-domains-landing        +59 B  (+0.0%)       +7 B  (+0.0%)

Common code that is always downloaded and parsed every time the app is loaded, no matter which route is used.

Sections (~8 bytes added 📈 [gzipped])

name            parsed_size           gzip_size
site-purchases        +16 B  (+0.0%)       +4 B  (+0.0%)
purchases             +16 B  (+0.0%)       +4 B  (+0.0%)

Sections contain code specific for a given set of routes. Is downloaded and parsed only when a particular route is navigated to.

Async-loaded Components (~1225 bytes added 📈 [gzipped])

name                                                    parsed_size            gzip_size
async-load-calypso-blocks-product-plan-overlap-notices      +7319 B     (new)    +2317 B     (new)
async-load-blocks-product-plan-overlap-notices              -4205 B  (-57.9%)    -1101 B  (-47.7%)
async-load-design-blocks                                      +57 B   (+0.0%)       +9 B   (+0.0%)

React components that are loaded lazily, when a certain part of UI is displayed for the first time.

Legend

What is parsed and gzip size?

Parsed Size: Uncompressed size of the JS and CSS files. This much code needs to be parsed and stored in memory.
Gzip Size: Compressed size of the JS and CSS files. This much data needs to be downloaded over network.

Generated by performance advisor bot at iscalypsofastyet.com.

[scinos]

I've been doing a few dry-runs to detect potential problems, mainly places where we assume package-relative imports (eg: import 'config'`): #45461, #45568, #45569, #44912.

After a few iterations, I think this is ready to be reviewed. e2e is passing, everything seems to work in calypso.live and doing a diff between old and new bundles I can't see anything obvious missing or extra.

This PR is likely going to have conflicts very soon. I'm happy to split it into smaller PRs (by directory maybe?) if you think that will make reviewing it easier.

[kwight]

I smoke tested a variety of things on the calypso.live branch, with no obvious issues – but you're right, it's all so massive 🙃

[tyxla]

@scinos looking at how quickly this got so many conflicts... I think it indeed might be best if we split it into chunks. It would surely add some overhead, but then it wouldn't be so scary for review 😬

[scinos]

I'm happy to split this per directory if that helps, it won't be a problem 👍

That being said, I don't think it will help a lot. The risk of this PR is not that I changed something that breaks (I trust eslint can do a string replacement correctly). The risk is that maybe I forgot some place where we assume package-relative imports (for example, somewhere where we look for imports of config and won't work with calypso/config). We won't be able to tell if there is some problem like that just looking at the changes at this PR.

Personally I think the best way to review this is to build master, build this branch (or run the auto-fix for the rule) and analyze the diff between the generated bundles.

[sgomes]

To get this merged, I'd suggest setting a freeze on the channel ahead of time, waiting a few minutes to make sure everyone is aware, and re-generating the PR based on trunk before merging. Then check everything is working correctly with a smoke-test of the whole application before turning the channel back green.

There doesn't seem to be much point in reviewing the PR; the approach seems solid, so it's just a matter of giving it a try now.

[tyxla]

FWIW I did some smoke testing and didn't find any trouble anywhere. Should be good to go, given that it's up to date with the latest master.

[scinos]

Update:

I changed this PR to apply the autofix only to files inside ./client/me/ for easier review and to reduce the chance of collisions.

In case it helps with the review, we already have many places where we import from calypso/<dir>, including the section loader (so it is definitely being used in prod). In other words, this PR is not introducing a new pattern, it is increasing the usage of an existing pattern. I hope that helps reduce the riskiness of this change.

[griffbrad]

👍🏻This is looking good to me at this point.

In case it helps with the review, we already have many places where we import from calypso/

, including the section loader (so it is definitely being used in prod). In other words, this PR is not introducing a new pattern, it is increasing the usage of an existing pattern. I hope that helps reduce the riskiness of this change.

This makes sense. Happy to review subsequent PRs applying the autofix more widely.

[tyxla]

I agree, let's go ahead with this one 🚢