-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
build: add Chakra CLI #12034
build: add Chakra CLI #12034
Conversation
✅ Deploy Preview for ethereumorg ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A couple of thoughts...
package.json
Outdated
@@ -3,7 +3,8 @@ | |||
"version": "8.0.0", | |||
"private": true, | |||
"scripts": { | |||
"dev": "next dev", | |||
"dev": "npx concurrently \"yarn next dev\" \"yarn theme:watch\"", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is very much a personal preference. concurrently is not added to the project as a dev dependency, but run remotely. The only requirement that would be prompted in the console is for the user to install it to their local machine. (This package is used in Chakra projects)
This command ensures that the dev environment and the Chakra CLI run in parallel without the user needing to remember an extra step.
Can certainly revert this if this is too much.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed, this is more of a personal preference. In that sense, I'd prefer to keep the dev
script as clean as possible.
However, I do see the benefit of running the Chakra script in parallel. We could add a comment in the readme or docs to let devs know how this works.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree that this should be opt-in with another script, not default npm dev
behavior, which should follow the standard. This could also bring some performance issues for some users, ram usage highly increased, etc, so should be optional.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have reverted the dev
script.
Would you want some comment added in this PR?
package.json
Outdated
"theme": "chakra-cli tokens ./src/@chakra-ui/theme.ts --strict-token-types --strict-component-types", | ||
"theme:watch": "chakra-cli tokens ./src/@chakra-ui/theme.ts --strict-token-types --strict-component-types --watch" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The strict-token-types
and strict-component-types
flags are used to constrain the typing, so that a combination of the string
and {}
primitives are not part of the type unions.
At the moment, this can aid in auto-completion. When talking with a member of the Chakra team, we recognized two issues (one kinda related):
- If we have a component that is taking is props that are typed with a shape from Chakra (i.e. StackProps) and you spread them into a component (i.e. Stack), you lose typing if you also directly add props to the component
<Stack
color="blue.500" // Typing lost here
{...props}
/>
- I would expect that with strict typing of the themes that TypeScript would throw an error if a typo or invalid token exists. This unfortunately does not seem to be the case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These flags have now been removed. More details in a later comment with additional findings.
tsconfig.json
Outdated
@@ -1,6 +1,6 @@ | |||
{ | |||
"compilerOptions": { | |||
"target": "es5", | |||
"target": "ESNext", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Otherwise an error throws with es5
:
Transforming object literal extensions to the configured target environment ("es5") is not supported yet
ES6
should also work here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Won't this affect our browser support? if not sure, I'd recommend doing this in a separate PR to run tests accordingly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pettinarip According to the CanIUse site, ES6 shows 98% support.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I failed to clarify that this errors throws on instances of using cssVar()
in component themes and attempting to compile dynamic keys... say:
[$colorBg.variable]: 'some value'
which is an ES6 only feature. Not sure if this is a Chakra CLI issue (doing testing in the Chakra package is not recreating the error), and really a typescript issue within this project.
I would point out that even the TypeScript docs also suggest es6 for the same reason as I mentioned above.
On initial failed build through Netlify, I believe this is exposing an inconsistency. When I would consider a script to run |
@pettinarip see the above comment. I'm going to stick this PR back into draft until I look at it further. Basically, the errors in the build were actually what I was hoping for, but was not expecting it to stay in a preview deploy check. I'm going to take some time to play around with this. If it gets too complicated, I'll remove the strict typing flags from the theme script and look at those later. I think restricting the typing if possible would help make sure typos or invalid token values are not overlooked and not bleed through. |
After further triage, I have removed those strict typing flags from the scripts, put this PR back to "Ready for Review" and propose the following:
|
package.json
Outdated
@@ -3,7 +3,8 @@ | |||
"version": "8.0.0", | |||
"private": true, | |||
"scripts": { | |||
"dev": "next dev", | |||
"dev": "npx concurrently \"yarn next dev\" \"yarn theme:watch\"", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed, this is more of a personal preference. In that sense, I'd prefer to keep the dev
script as clean as possible.
However, I do see the benefit of running the Chakra script in parallel. We could add a comment in the readme or docs to let devs know how this works.
tsconfig.json
Outdated
@@ -1,6 +1,6 @@ | |||
{ | |||
"compilerOptions": { | |||
"target": "es5", | |||
"target": "ESNext", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Won't this affect our browser support? if not sure, I'd recommend doing this in a separate PR to run tests accordingly.
@@ -1,6 +1,6 @@ | |||
{ | |||
"compilerOptions": { | |||
"target": "es5", | |||
"target": "ES6", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pettinarip your question here and my response was removed due to a minor change I did.
So as to if this effects browser support, ES6 is supported by roughly 98% from caniuse.com.
The TypeScript docs of course also recommends ES6
Because there are dynamic keys in some component themes (i.e. [$border.variable]
), the CLI will fail with the ES5
target because dynamic keys are part of theES6
spec.
@pettinarip Personally would just add a |
I'd prefer to minimize the number of scripts we have to make it simpler and more manageable. But if you think that adding that script will add value and will be used by a majority of devs, then I'd totally support that. What I wouldn't want to happen is to have a lot of scripts that nobody uses. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! thanks @TylerAPfledderer
Description
This PR adds back in the Chakra CLI to generate typing based on the custom theme configuration. This is helpful for IDE auto-completion to be able to recognize the correct tokens.
yarn install
has runRelated Issue
N/A