feat(dev-cli): Add clerk-dev CLI tool - #3689
Conversation
🦋 Changeset detectedLatest commit: 285bc39 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
| fapiUrl: 'REPLACE_WITH_FAPI_URL', | ||
| bapiUrl: 'https://api.clerk.com', |
There was a problem hiding this comment.
I put these in since these values are displayed on the configuration screen in the dashboard. I'm not totally sure of when a user would need to have these values available.
There was a problem hiding this comment.
Then let's remove it for now 👍
| if (process.env.VISUAL) { | ||
| spawn(process.env.VISUAL, [CONFIG_FILE], { | ||
| stdio: 'inherit', | ||
| env: { | ||
| ...process.env, | ||
| }, | ||
| }); | ||
| console.log(`Configuration file written to ${CONFIG_FILE}.`); | ||
| } else if (process.env.EDITOR) { | ||
| spawn(process.env.EDITOR, [CONFIG_FILE], { | ||
| stdio: 'inherit', | ||
| env: { | ||
| ...process.env, | ||
| }, | ||
| }); | ||
| console.log(`Configuration file written to ${CONFIG_FILE}.`); | ||
| } else { | ||
| console.log(`Configuration file written to ${CONFIG_FILE}. Replace with your values.`); | ||
| } |
There was a problem hiding this comment.
The README didn't mention this functionality. So it tries to open the editor so that you edit the secretKey/publishableKey.
Alternatively, you could also ask for these two values (+ the name for an instance) during init and write them to the file directly. Then it's all happening in the CLI
There was a problem hiding this comment.
In a future iteration the plan is to have this automatically configured by the clerk-dev auth command, so I didn't want to spend the time setting up a prompt-based configuration. However it's looking like clerk-dev auth might be a ways off, so it might be worth exploring in a follow-up PR.
| */ | ||
| export async function setup({ js = true }) { | ||
| console.log('Installing monorepo versions of Clerk packages from package.json...'); | ||
| await linkDependencies(); |
There was a problem hiding this comment.
I thought we wanted to support other tools (e.g. secco or yalc). Wouldn't this step be better placed into watch so that I can still run setup but use e.g. secco for the rest of the flow?
There was a problem hiding this comment.
I've added a --skip-install option to allow for this! The idea is that clerk-dev setup will intelligently choose the right installation mechanism depending on framework. Next.js and Vite seem to work fine with npm install, so that's the default at the moment, but once we add support for other frameworks you'll see this command branch into other tools like secco.
But, in the event you want the framework configuration but not the dependency configuration, you can now use clerk-dev setup --skip-install.
| .option('--js', 'only start the watcher for clerk-js') | ||
| .option('--no-js', 'do not spawn the clerk-js watcher (macOS only)') |
There was a problem hiding this comment.
These two boolean flags feel a bit awkward, what happens if in the future one wants to not spawn other things?
How about replacing this with an --ignore flag that accepts multiple values?
Then the default is that clerk-js is built, too, and one can use --ignore to not build it or other stuff
There was a problem hiding this comment.
With --no-js, we can align with the flags passed to clerk-dev setup. So for example, clerk-dev setup --no-js would be followed by clerk-dev watch --no-js. On Linux you could do clerk-dev setup --no-js followed by clerk-dev watch since watch doesn't spawn the clerk-js builder on Linux. I can definitely see the awkwardness when you factor in the Linux implementation, but given our entire team uses macOS I felt that was acceptable. Is there another flag that would be less awkward but retain the alignment with clerk-dev setup so that users don't need to learn two different flags?
I think the --ignore flag is a good idea, but is something I'd like to save for later once we have a better idea of what situations would cause a developer to want to ignore other packages.
Co-authored-by: Lennart <lekoarts@gmail.com>
LekoArts
left a comment
There was a problem hiding this comment.
Marking as "Approve" as generally I think it's mostly good to go. So you're unblocked if you want to merge today.
Left some two smaller comments on this new review iteration.
As for the older comments:
- I'd like us to publish it but wouldn't mind doing that at a later stage if we don't want to do it just now
--jsand--no-jsstill feels awkward as mentioned
| You can use the `set-instance` command to switch between `activeInstance` afterwards: | ||
|
|
||
| ```shell | ||
| clerk-dev set-instance yourName | ||
| ``` |
There was a problem hiding this comment.
config was missing 👍
| You can use the `set-instance` command to switch between `activeInstance` afterwards: | |
| ```shell | |
| clerk-dev set-instance yourName | |
| ``` | |
| You can use the `set-instance` command to switch between `activeInstance` afterwards: | |
| ```shell | |
| clerk-dev set-instance yourName | |
| ``` | |
| If you have the `VISUAL` or `EDITOR` environment variable set in your shell, you can open the configuration like so: | |
| ```shell | |
| clerk-dev config | |
| ``` |
| export default function cli() { | ||
| const program = new Command(); | ||
|
|
||
| program.name('clerk-dev').description('CLI to make developing Clerk packages easier').version('0.0.0'); |
There was a problem hiding this comment.
Nit: Use the version from package.json to set the .version()
| fapiUrl: 'REPLACE_WITH_FAPI_URL', | ||
| bapiUrl: 'https://api.clerk.com', |
There was a problem hiding this comment.
Then let's remove it for now 👍
Co-authored-by: Lennart <lekoarts@gmail.com>
Description
This PR adds the
@clerk/devpackage containing theclerk-devCLI tool, which is intended to simplify the workflow for iterating on packages in this repo within sample applications. More information including available commands can be found in the README.This initial version is compatible with Next.js and Vite, with more frameworks to come in the future.
Checklist
npm testruns as expected.npm run buildruns as expected.Type of change