feat(telemetry): Capture bundler flag

[dac09]

Captures the bundler being used in the project.

⚠️ Note
Requires modifying the database with a new column

	`webBundler` varchar(255) DEFAULT 'webpack',

[replay-io]

15 replays were recorded for a8f83b1.

0 Failed

15 Passed

• useAuth hook, auth redirects checks
• Check that tags are rendering the correct dynamic data
• Check that a specific blog post is prerendered
• Check that about is prerendered
• Check that homepage is prerendered
• Check that you can navigate from home page to specific blog post
• Waterfall prerendering (nested cells)
• RBAC: Admin user should be able to delete contacts
• RBAC: Should not be able to delete contact as non-admin user
• Smoke test with dev server
• Smoke test with rw serve
• Loads Cell mocks when Cell is nested in another story
• Loads Cell Stories
• Loads MDX Stories
• Mocks current user, and updates UI while dev server is running

View test run on Replay ↗︎

[cannikin]

Nice! Check out the schema.sql file in the root of the telemetry.redwoodjs.com repo, that's a snapshot of the DB schema, and should contain that new webBundler field. I don't apply that schema to the database or anything, but it lets us know what it should be if we ever need to re-deploy.

I can add that field to the production DB at any time, and then if you create a test project from your repo any commands you run should send telemetry, including your new field. Then we can verify by just checking the database for the new field. (For such a small change it's actually easier to just do it for real than try to run everything locally.)

[dac09]

Yeah I tested it with the verbose flag, even without the DB change the request seems to be accepted.

❯ yarn rw dev
Redwood Telemetry Payload {
  type: 'command',
  command: 'dev',
  duration: null,
  uid: 'c4134b9f-11cd-4b67-bcb8-e825ed943c5c',
  ci: false,
  redwoodCi: false,
  NODE_ENV: null,
  os: 'macOS',
  osVersion: '13.0.1',
  shell: 'zsh',
  nodeVersion: '16.17.0',
  yarnVersion: '3.2.3',
  npmVersion: '8.15.0',
  vsCodeVersion: '1.74.3',
  redwoodVersion: '4.0.0',
  system: '8.24',
  webBundler: 'webpack',
  complexity: '12.2.6.13',
  sides: 'web,api'
}
Redwood Telemetry Response: Response {
  [Symbol(state)]: {
    aborted: false,
    rangeRequested: false,
    timingAllowPassed: true,
    requestIncludesCredentials: true,
    type: 'default',
    status: 200,
    timingInfo: {
      startTime: 1040.8170000314713,
      redirectStartTime: 0,
      redirectEndTime: 0,
      postRedirectStartTime: 1040.8170000314713,
      finalServiceWorkerStartTime: 0,
      finalNetworkResponseStartTime: 0,
      finalNetworkRequestStartTime: 0,
      endTime: 0,
      encodedBodySize: 632,
      decodedBodySize: 632,
      finalConnectionTimingInfo: null
    },
    cacheState: '',
    statusText: 'OK',
...
}

I'll merge this in, and when you migrate the DB (I tried running SQL file locally on Postgres, but it syntax errors out) - we can pull it into the RC branch?

[thedavidprice]

@dac09 @cannikin cc @jtoar @Josh-Walker-GM
Sorry I missed this one. I was just talking to Dom about this yesterday.

For features that are preview and/or experimental (both Vite and Redwood Record), I suggest we create a specific TOML section, e.g. [preview-features], instead of modifying any existing config. This would have a couple maintainability and UX advantages:

• explicit about what is experimental and/or preview (including discoverability of available preview features)
• we don't have to continually update Telemetry JSON, instead we can just create a new field for previewFeatures and pass string list just like we do for the command field
• we don't have to update https://telemetry.redwoodjs.com every time we have a new feature

What say you all? Is this a change we can make for 4.1:

1. remove web.bundler; replace with something like previewFeature.vite
2. update Telemetry packet accordingly
3. update https://telemetry.redwoodjs.com

[dac09]

Hey yooo DP! I’d like to suggest not making this change at this time:

1. The content (video/guides,etc.) has already gone out on how to change the bundler to Vite. Although we are totally in the clear to change it for RC (semver wise), I think it’s hard enough to get people to try new things, and making this change now would be us rowing backwards.
2. To make features opt-in is a ,huggge, amount of work because you need to support both options, so we need to balance the effort required there with how significant the change is. Swapping a bundler is no small change, and I felt the effort was justified. In other cases, we’ll definitely have to think it through.
3. RedwoodRecord isn’t really opt-in in the same way vite is. While I agree with the experiments section has discoverability advantages, in the case of RR it would just be a fake flag we’re introducing - it wouldn’t really change how RW builds/runs your app.

But… should we have a way of seeing what experimental things people are using? Absolutely!

[thedavidprice]

Not swayed by these but I also don’t want to add friction to this getting shipped.

I definitely don’t want us to follow this current pattern for future experimental features (instead favoring the separate TOML section), both for the reasons I stated above but also because it feels like it unintentionally communicates these features are “locked into the roadmap”; e.g. we are going to have a bundler config option for web ongoing.

Understood about Redwood Record and how this would feel artificial, which comes back to my primary point — I want us to standardize how we structure experimental features both to make it easier for discovery and setup as well as for us to understand usage and performance.

Your call, but the following content does need to be updated with this release:

• https://redwoodjs.com/docs/canary/cors#redwoodtoml-config
• https://telemetry.redwoodjs.com