@LeaVerou You can preview the survey here: https://survey.alchemer.com/s3/7243449/MDN-Web-Components-Short-Survey

Summary

Problem

We make a whoami request on each page, which is served from rumba. When developing locally, we usually set REACT_APP_KUMA_HOST=localhost:8000. However, if rumba is then not running, this produces multiple failed requests in the DevTools' network tab.

Solution

If the whoami request fails during development, return an empty response.

How did you test this change?

1. Set REACT_APP_KUMA_HOST=localhost:8000 in .env.
2. Run yari dev.
3. Make sure rumba is not running at localhost:8000.
4. Open http://localhost:3000/en-US/docs/Web and verify in DevTools' network tab that the /api/v1/whoami request succeeds anyways.

chore(deps): bump open from 8.4.2 to 9.0.0 (#8452)

chore(deps-dev): bump @swc/core from 1.3.41 to 1.3.42 (#8471)

chore(deps): bump html-react-parser from 3.0.12 to 3.0.13 (#8472)

chore(deps): bump @mdn/browser-compat-data from 5.2.43 to 5.2.44 (#8473)

Merge branch 'main' into gcp

Summary

Problem

The /api path should be reserved for our rumba API, but the MDN Plus plans are currently served from api/v1/stripe/plans, which is actually backed by a Lambda that determines the available plans based on the country.

Solution

Use /plus/plans.json instead of /api/v1/stripe/plans, which are both essentially the same CloudFront behavior, just with a different path.

How did you test this change?

Ran yarn dev and visited http://localhost:3000/en-US/plus.

refactor(client): rename {Stripe => Plus}Plans

chore(client): use /plus/plans.json

Instead of api/v1/stripe/plans, because those are not actually served from our Rumba API.

refactor(MP-267): extract filenames to variable/constant

mdn@mozilla.com does not actually exist.

Checklist for reviewer:

• [ ] Commits should reference a bug or github issue, if relevant (if a bug is referenced, the pull request should include the bug number in the title).
• [ ] If the PR comes from a fork, trigger integration CI tests by running the Push to upstream workflow and provide the <username>:<branch> of the fork as parameter. The parameter will also show up in the logs of the manual-trigger-required-for-fork CI task together with more detailed instructions.
• [ ] If adding a new field to a query, ensure that the schema and dependent downstream schemas have been updated.
• [ ] When adding a new derived dataset, ensure that data is not available already (fully or partially) and recommend extending an existing dataset in favor of creating new ones. Data can be available in the bigquery-etl repository, looker-hub or in looker-spoke-default.

For modifications to schemas in restricted namespaces (see CODEOWNERS):

• [ ] Follow the change control procedure

/remind me about this in April

/remind me tomorrow

See also: https://github.com/mozilla/bigquery-etl/pull/3677

Checklist for reviewer:

• [ ] Commits should reference a bug or github issue, if relevant (if a bug is referenced, the pull request should include the bug number in the title).
• [ ] If the PR comes from a fork, trigger integration CI tests by running the Push to upstream workflow and provide the <username>:<branch> of the fork as parameter. The parameter will also show up in the logs of the manual-trigger-required-for-fork CI task together with more detailed instructions.
• [ ] If adding a new field to a query, ensure that the schema and dependent downstream schemas have been updated.
• [ ] When adding a new derived dataset, ensure that data is not available already (fully or partially) and recommend extending an existing dataset in favor of creating new ones. Data can be available in the bigquery-etl repository, looker-hub or in looker-spoke-default.

For modifications to schemas in restricted namespaces (see CODEOWNERS):

• [ ] Follow the change control procedure

Can we add a markdownlint rule like the one fully-qualified developer.mozilla.org URLs?

https://github.com/mdn/content/blob/0053e22667809069b5a62c3de80122cdb65d611c/.markdownlint-cli2.jsonc#L184-L190

Caused the query to be missing its first character:

ss.properties.background instead of css.properties.background

Noticed as part of https://github.com/mdn/yari/pull/8470.

Summary

Fetches BCD data from the separate bcd.developer.mozilla/allizom.org host.

Problem

We have moved the BCD data off to a separate subdomain as part of our (ongoing) migration from AWS to GCP, but we're still fetching BCD data for BCD tables from /bcd/*.

Solution

• Introduce an environment variable REACT_APP_BCD_BASE_URL, defaulting to stage (https://bcd.developer.allizom.org).
• Use it for fetching the data for the BCD table.
• Use bcd.developer.mozilla.org for the prod build.

Screenshots

Before

After

How did you test this change?

Ran yarn dev, then opened http://localhost:3000/en-US/docs/Web/CSS/background#browser_compatibility locally, verified that the BCD data is fetched from bcd.developer.allizom.org and properly displayed, then blocked the URL in the DevTools and verified that the BCD data is no longer displayed.

chore(eslint): ignore copied libs

fix(libs): add engines.node to package.json

Avoids these linting errors:

• Rest/spread properties are not supported until Node.js 8.3.0. The configured version range is '>=8.0.0'
• The 'URL' is not supported until Node.js 10.0.0. The configured version range is '>=8.0.0'
• RegExp named capture groups are not supported until Node.js 10.0.0. The configured version range is '>=8.0.0'

MP-267 - Use project id, not name

Co-authored-by: Brett Kochendorfer brett.kochendorfer@gmail.com

Checklist for reviewer:

• [ ] Commits should reference a bug or github issue, if relevant (if a bug is referenced, the pull request should include the bug number in the title).
• [ ] If the PR comes from a fork, trigger integration CI tests by running the Push to upstream workflow and provide the <username>:<branch> of the fork as parameter. The parameter will also show up in the logs of the manual-trigger-required-for-fork CI task together with more detailed instructions.
• [ ] If adding a new field to a query, ensure that the schema and dependent downstream schemas have been updated.
• [ ] When adding a new derived dataset, ensure that data is not available already (fully or partially) and recommend extending an existing dataset in favor of creating new ones. Data can be available in the bigquery-etl repository, looker-hub or in looker-spoke-default.

For modifications to schemas in restricted namespaces (see CODEOWNERS):

• [ ] Follow the change control procedure

Checklist for reviewer:

• [ ] Commits should reference a bug or github issue, if relevant (if a bug is referenced, the pull request should include the bug number in the title).
• [ ] If the PR comes from a fork, trigger integration CI tests by running the Push to upstream workflow and provide the <username>:<branch> of the fork as parameter. The parameter will also show up in the logs of the manual-trigger-required-for-fork CI task together with more detailed instructions.
• [ ] If adding a new field to a query, ensure that the schema and dependent downstream schemas have been updated.
• [ ] When adding a new derived dataset, ensure that data is not available already (fully or partially) and recommend extending an existing dataset in favor of creating new ones. Data can be available in the bigquery-etl repository, looker-hub or in looker-spoke-default.

For modifications to schemas in restricted namespaces (see CODEOWNERS):

• [ ] Follow the change control procedure