Skip to content

Catalyst 1744 refactor configuration variables#2866

Open
jamesqquick wants to merge 16 commits intocanaryfrom
CATALYST-1744-refactor-configuration-variables
Open

Catalyst 1744 refactor configuration variables#2866
jamesqquick wants to merge 16 commits intocanaryfrom
CATALYST-1744-refactor-configuration-variables

Conversation

@jamesqquick
Copy link
Contributor

@jamesqquick jamesqquick commented Feb 6, 2026

What/Why?

Refactor config variables:

Rename environment variables from BIGCOMMERCE_ prefix to CATALYST_ prefix

BIGCOMMERCE_STORE_HASH -> CATALYST_STORE_HASH

BIGCOMMERCE_PROJECT_UUID -> CATALYST_PROJECT_UUID

BIGCOMMERCE_FRAMEWORK -> CATALYST_FRAMEWORK

BIGCOMMERCE_ACCESS_TOKEN - > CATALYST_ACCESS_TOKEN

Implement new priority for config variables

  1. Individual parameter flags (e.g. --store-hash)
  2. --env-file flag
  3. process.env
  4. .bigcommerce/project.json

Add --env-file flag

This allows the user to specify a environment variable file to load variables from

Remove default environment variable file

Remove the reading of default environment variable files. This requires the user to pass --file-env if they want variables to be read from a file.

Expand project.json

Write additional config variables to project.json file.

projectUuid
framework
storeHash
accessToken

Improved logging

Update logs to details which variables are required and how/where to set them

Testing

Tests have been added to test basic functionality. One thing the tests do not cover is when the user is passing the --env-file flag to specify an environment variable file to read from. For testing,

  • rename environment variables to match CATALYST_ prefix
  • run CLI command (ex. project list) without passing any flags. It should fail since no env file is being picked up automatically
  • run catalyst project create command to generate a new project and verify the correct properties are set in project.json
  • catalyst project list - should now work by reading variables from project.json
  • run catalyst project list --access-token dummy-token and pass dummy variable for access token via --access-token flag. This should fail since the explicitly passed access token isn't valid
  • create .env.test with invalid access token. Then, run catalyst project list --env-file .env.test and show that the command fails since it picked up the invalid access token
  • test other combinations of variable configurations to confirm priority order is respected

Migration

@vercel
Copy link

vercel bot commented Feb 6, 2026

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
catalyst Ready Ready Preview, Comment Feb 11, 2026 11:23am

Request Review

@changeset-bot
Copy link

changeset-bot bot commented Feb 6, 2026

⚠️ No Changeset found

Latest commit: 6091753

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@jamesqquick jamesqquick force-pushed the CATALYST-1744-refactor-configuration-variables branch from 84dcd1a to 6091753 Compare February 10, 2026 20:25
@jamesqquick jamesqquick marked this pull request as ready for review February 10, 2026 20:34
@jamesqquick jamesqquick requested a review from a team as a code owner February 10, 2026 20:34
Copy link
Contributor

@matthewvolk matthewvolk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ I just realized now that we're storing access token in .bigcommerce/, the root .gitignore contains a line to ignore .bigcommerce but the core/.gitignore does not. Since eventually, core/.gitignore will be the ignore file shipped to customers, and they won't have the root ignore file, can we please add .bigcommerce to core/.gitignore?

Comment on lines +9 to +11
const envFileIndex = process.argv.findIndex(
(arg) => arg === '--env-file' || arg.startsWith('--env-file='),
);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This works but I think it's fragile... I'm not sure it'll handle edge cases like --env-file being passed after -- (which Commander uses to stop option parsing).

If we're ok with that, that's fine. We can always merge and re-evaluate if it starts behaving undesirably.

consolaPromptMock.mockRestore();
});

test('prompts to create a new project', async () => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this test name is a duplicate of the test on line 164 in this same file. I see the following:

  • line 164: test('prompts to create a new project', ...) - the happy path where the user selects "create" and it succeeds
  • line ~221: test('prompts to create a new project', ...) - the error path where the API returns a 502

Maybe we rename the second one to "errors when project creation fails" or something?

Comment on lines -309 to +310
'BIGCOMMERCE_STORE_HASH=123',
'BIGCOMMERCE_STOREFRONT_TOKEN=456',
'CATALYST_STORE_HASH=123',
'CATALYST_ACCESS_TOKEN=456',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was this intentional, to rename BIGCOMMERCE_STOREFRONT_TOKEN to CATALYST_ACCESS_TOKEN?

{
type: 'secret',
key: 'BIGCOMMERCE_STOREFRONT_TOKEN',
key: 'CATALYST_ACCESS_TOKEN',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was this intentional, to rename BIGCOMMERCE_STOREFRONT_TOKEN to CATALYST_ACCESS_TOKEN?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I actually just realized I made that jump. I think I just had access_token in my mind and put that in the different docs, then copied in. I don't think we made a collective decision on that. I think the correct thing to do would be CATALYST_STOREFRONT_TOKEN. Does you agree with that?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wait ignore the above lol I get it now. This is supposed to be testing parsing secret runtime variables. Great catch!

Copy link
Contributor

@chanceaclark chanceaclark left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we split this up into separate changes for each thing you are doing here?

@jamesqquick
Copy link
Contributor Author

Can we split this up into separate changes for each thing you are doing here?

Into separate PRs you mean? I wondered about it being too much in one. I can do that!

@jamesqquick
Copy link
Contributor Author

Splitting this into separate PRs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants