I am able to use commitizen with interactive mode as expected. However in non-interactive mode is not functioning.
git-cz --non-interactive --type=feat --subject="add onClick prop to component"
cz-cli#4.2.3, cz-conventional-changelog#3.3.0
? Select the type of change that you're committing: (Use arrow keys)
❯ feat: A new feature
fix: A bug fix
docs: Documentation only changes
style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
refactor: A code change that neither fixes a bug nor adds a feature
perf: A code change that improves performance
test: Adding missing tests or correcting existing tests
(Move up and down to reveal more choices)
What could be going wrong here?
Ref : https://www.npmjs.com/package/git-cz
The --non-interactive syntax is supported by another library git-cz (https://github.com/streamich/git-cz).
Weirdly enough commitizen (https://github.com/commitizen/cz-cli) also has the same keyword "git-cz" but unfortunately it does not support non-interactive mode yet!
Related
Whenever I build a React Native app, I get hundreds of warnings that do not prevent the build from being successful. For example, I almost always see many errors like The iOS deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to 8.0, but the range of supported deployment target versions is 9.0 to 14.4.99..
What I Want To Know: I ignore these warnings because they're not errors. Is there ever a reason to not ignore them? For example, is it possible that even though they don't affect a given build, they might affect a future one and I should try to resolve them now? Or are many of these warnings part of node modules that I can't change, and I should always ignore them?
Yes you can easily disable them. At the end of my talk I will show you how to do this.
But:
Warnings can sometimes be very helpful.
However, when you are developing your project, they are very annoying and cause console clutter and confusion.
Whenever I am developing a component, I disable alerts at the beginning. And after the development of a component is finished, I reactivate the alerts to be notified that my component performance is improving.
For example, React says you should always use an key attribute in map statements. But well, sometimes I forget to do it. Do not insert key is not a mistake. But for reasons (which are not allowed here) it is better to use it.
So I suggest you do the same. This can be done simply with the following command:
console.disableYellowBox = true;
For example
export default class MyClass extends React.Component {
render() {
console.disableYellowBox = true;
return (...);
}
}
Also you can include console.disableYellowBox = true; after your imports.
I'm writing React with Typescript and, after making a change to my code, I started seeing Objects are not valid as a React child errors.
I had changed a property from a string to an Optional<string>, so the error totally makes sense since my <div>{property}</div> code was no longer correct.
So, this is a type error being caught at runtime.
I'm not doing any casting or any other code "tricks" to try to subvert pre-existing type checking; I'm just rendering a value that React detects at runtime to be an object.
It seems to me that an appropriate linting rule or typescript configuration should have been able to capture that property is no a valid React child.
Here's a very simple example (TSPlayground):
type Props = {
example:{}
};
const Foo = ({example}: Props) => <div>{example}</div>
I would expect an error pointing to the use of example inside the JSX.
I've been doing some googling, but I can't find a rule that seems like it would catch this.
Is there one that anyone knows of?
As others have mentioned there's no such a feature available right now. Furthermore linters are more geared towards styling than capturing compilation errors. I don't think what you're asking is possible because example is a dynamic type and setting it to a string makes it a valid JSX node while setting it to an object makes it invalid. Since JS is a dynamic language we cannot know this ahead of time. Typescript helps in this case, but that's a separate type system from eslint rules and as #jonrsharpe has mentioned in the comments there's an issue on typescript repository to add the feature you're requesting (#35622).
ESlint seems to be very clear; it wants a valid link to be used inside the anchor tag. But I want to use it this way and I don't want to replace this anchor with a button or something else.
Also, the warning is not persistent. Sometimes it disappears. What I want to know is why is this happening? What is wrong with using an anchor without a reference actually ?
Warning comes from the following piece of code.
<a
key={randKey}
className="list-icons-item"
data-action={this.props.headerElements[i]}>
</a>
How can I disable this warning or what is the best practice ?
The question poses a simple example of a complex problem. If the intent of the code is to focus this.props.headerElements[i], then give this.props.headerElements[i] an ID and reference that id in the href of the link. Let the default behavior do its job. No further script logic is required.
If there is no navigation involved, then, as #Andy points out, the anchor is not suitable. Use a button as the documentation for the rule emphatically recommends.
When a control looks like a link and navigates off the page or changes focus on the page, a link is the semantically correct choice, per WAI ARIA specifications. If what you need to focus will be shown as part of your click handler logic, then you may find the ESlint jsx-a11y anchor-is-valid warning counterproductive. In that case, you are best served using an anchor with explicit role and tabindex attributes and suppressing the rule or turning it off in your .eslintrc file as #Andy also mentions above.
<a
role="link"
tabIndex="0"
key={randKey}
className="list-icons-item"
data-action={this.props.headerElements[i]}>
There are costs when semantics diverge from appearance. Consider a blind user calling your web application's help desk and being directed to click a link but hearing only a button announced in the screen reader. Consider a user who has only partial sight encountering a control which looks like a link and functions like a link but is marked up as a button. The user will hear one thing announced in the screen reader and see something else.
These trade offs need to be considered early in life cycle of your project so you can be consistent with your treatment throughout your application.
I'm trying to inline-bind my functions using this kind of syntax:
onChange = () => {
}
However, my sublime editor isn't correctly highlighting it:
I'm using the Babel package for sublime for syntax highlighting.
Does anyone know how to make it recognize this sort of style?
Check this
View -> Syntax -> Open all with current extension as... -> Babel -> Javascript(Babel).
or
Ctrl - Shift - P, type "Babel" and select Set Syntax: Javascript(Babel)
Source
ST3 relies on language definitions for providing language features such as code folding, syntax highlighting etc. However, with JavaScript, you have many different flavors of the language - like ES5, ES6, JSX etc. To correctly understand and parse each one of them is not easy given ST3's design (using a language definition file which is mostly regex matching).
So depending on what you're looking for, you may want to install JavaScriptNext - ES6 Syntax which helps ST3 better understand the language and its syntax. There are few others like these on marketplace if I'm not mistaken.
Then comes the notion of syntax highlighting - again, without the core editor natively understanding what's JS and what's JS-like out, these plugins are dependent on how good the language definitions are and so, have one or more shortcomings. There are a few options that you can try and see what suits best:
naomi - Enhanced syntax definitions for Sublime Text 3. Supports stage-0 features
babel-sublime - Syntax definitions for ES6 JavaScript with React JSX extensions. But has some issues with arrow functions, see #301
sublime-react - It's actually deprecated in favor of babel-sublime but you may want to check it out.
Whatever you choose, you need to do some due diligence. Check with their issue lists, see if anything stands out to you. Relying on transpilers can only go so far.
As a long time ST3 user, I've constantly found one or more issues. And depending on whether you're working on pure JS, or React, you may have to keep switching or accept some compromises.
Ultimately, I switched to VSCode (tried Atom too) which understand the language and it's flavors natively and provides extensions API that authors can build upon. Consequently, the syntax understanding and highlighting capabilities are far greater than what you can get out of ST3 + Extensions.
The only solution that comes to mind is to create a custom snippet, for Sublime, to "recognize" the arrow function or in general the reduced syntax to declare a function.
Here are two links that could be useful:
https://medium.freecodecamp.org/a-guide-to-preserving-your-wrists-with-sublime-text-snippets-7541662a53f2
and
https://gist.github.com/LeZuse/2324352
or
https://gist.github.com/ZYinMD/860926a178ccd6d107ffe2c6727b5845
Is there a way to do some checks before allowing a merge in Mercurial?
I have found the pre-update hook and have a script that runs before an update is allowed, by adding the following to ~/.hg/hgrc:
[hooks]
pre-update = ~/hg_pre_update.sh
But I'd like to run the check before allowing a merge as well, and currently it just allows the merge to go through without running my checks.
Background
In case there are alternative ways to solve the problem...
We have been having a number of problems with 'lost' edits under Mercurial. I've tracked down most of them now to the same underlying cause: someone has vim edit sessions open while either they or someone else does a hg update or merge. The editor warns the file has changed externally, the user ignores the warning and saves their changes.
When these changes are committed, for Mercurial there is nothing controversial. The user has simply reverted all the changes brought in with the last update and put in their own changes.
Some time later, we notice the code has gone walkabouts. Cue assorted insults flung the way of mercurial...
Set vim to autoreload changes if no local changes where done. (otherwise ask, or force a merge)
that's how I avoid such issues in any editor...
Sorry just worked out there is a pre-merge hook that works just the same as pre-update. I tried it before asking the question, but now just looking at my hgrc I realise I put the script being called for that hook to ~/hg_pre_merge.sh which doesn't exist.
I can't find the existence of pre-merge documented anywhere but still feeling like a bit of a muppet now.