elsewhencode / project-guidelines Goto Github PK
View Code? Open in Web Editor NEWA set of best practices for JavaScript projects
License: MIT License
A set of best practices for JavaScript projects
License: MIT License
Why : "Even though your build process can(should) get rid of them, make sure that your code style checker warns you about leftover console logs."
As a beginner, this doesn't explain me (at all) why it should be avoided. Printing startup data (ip/port etc...) doesn't seem to hurt, does it ?
Thanks for clearing-up this point :)
I want to translate this guideline by forking a repo if you approve.
In 1.2, we can read the following:
You can use --autosquash to squash all your commits to a single commit. Nobody wants many commits for a single feature in develop branch. read more...
I think that asserting that nobody wants that is a fallacy. There are good reasons for which you would want to keep those commits separated even in develop branch:
Those are the reasons why I never squash my commits into a feature commit. You should therefore mention in your guidelines that this is subjective.
Lots of trailing spaces. I have Sublime configured to remove those on save. It created a huge diff. I think they should be removed and there should be a linter checking those prior to merge.
Hello Team Hive!
Great job on this so far, I would suggest in the git workflow section you add steps to setup a repository which are currently missing. I would like to add these as the first steps. They will give you standard branches used in your workflow (ie develop / feature / bugFix etc)
git init
git flow init
More than happy to PR
Maybe its an idea to use dotenv-safe, with that you can define the needed env variables in the .env.example
(the optional ones can be prefixed with #
).
In section 7 it says:
Always use //TODO: comments to remind yourself and others about an unfinished job.
Some developers avoid // TODO
and prefer to open a ticket for any single reminder. This is to prevent TODOs from piling up in the source code.
I personally use a combination of them and I use // TODO
mostly to remind myself if there is a need for refactoring.
I think the best approach is using //TODO(#3456)
where the number is a ticket and it's enforced by a lint rule. Should we add a sub-section for this? any thoughts/suggestions?
Hey. Thanks for your awesome project guidlines.
In the en doc, there is one step in the Gitflow that maked me confused when I polished the zh one.
Update your feature branch with latest changes from develop by interactive rebase.
git checkout
git rebase -i --autosquash develop
To my certain knowledge which may be wrong, the git rebase -i --autosquash develop
command is used to update develop branch with the changes you have make in the feature branch. Did I misunderstand it? Look forward to your reply.
There are exclamation marks in .gitignore
file.
.vscode/*
!.vscode/settings.json
!.vscode/tasks.json
!.vscode/launch.json
!.vscode/extensions.json
Why preffered like that?
Is extremely useful for projects with more than 1 developer working on the code!
Hello,
Recently we discussed in the Topcoder Community, and people have different opinions regarding errors messages.
From your best practices:
Response messages must be self-descriptive. A good error message response might look something like this:
// (1)
{
"code": 1234,
"message" : "Something bad happened",
"description" : "More details"
}
or for validation errors:
// (2)
{
"code" : 2314,
"message" : "Validation Failed",
"errors" : [
{
"code" : 1233,
"field" : "email",
"message" : "Invalid email"
},
{
"code" : 1234,
"field" : "password",
"message" : "No password provided"
}
]
}
Based on my understanding, (1) schema can be used as a general error format, and (2) schema can be used for a specific situation (validation errors in this case).
That means error responses don't have to have the exact format with the same properties.
Some developers insist that all error responses should be consistent and be the same.
Could you clarify it according to your best practices in this project?
Need to create a CI type checker before merge. Caught a markup bug in #107.
I like the part about API design, it's in a nutshell and concise.
If I may, the API Versioning part is actually dear to me since we've been rolling this solution out at work and I spun-up a modular and lightweight middleware for Express which does exactly that: https://github.com/lirantal/express-version-route
Would it be ok to reference it in the README?
Write testable code, avoid side effects, extract side effects, write pure functions
Appears two times.
I guess it's a mistake? In the first section, there's only explanation about Pure Functions, so I think that its title could be 'Write Pure Functions'.
what do you think about https://github.com/shieldfy/API-Security-Checklist
I think Prettier Should be added to the code style recommendations, no?
Hi there,
I have a question about git flow(i am not sure about it's type of flow). Please help me answer this question. I really appreciate your time.
We have a central repository with a branch called "feature-branch-A".
We have 4 peoples(include me) are working on that branch. So those people will fork that center repo (create their own public repo) and work on "feature-branch-A".
After some days, when i am done with my task(task 1), i pushed code to my own public repo and created a PR for merging to "feature-branch-A" on the central repo. But unfortunately my team lead disapproved my PR(we don't need that task 1 anymore) and force me working on other task(task 2) not related to the current task(task 1) (but both still in the "feature-branch-A").
In that situation, what is the best practices for handling my public own repo?
Thank you so much for reading my question.
How about immigrate those guidelines to Gitbook?
Hello,
I would like to include some other editors such as Eclipse in the workspace exclude for the .gitignore.
Happy to PR if you feel appropriate
I want to translate this guideline by forking a repo if you approve.
Since the guides were written long time back, most of the references to the main branch are master. And most of the organizations are making a move to have an inclusive language, even Github started renaming the master branch as main. Can we please update the guides for the same?
Like, there's no develop or any other branches (which is considered necessary in this guideline). Everyone pushes directly to the master branch.
I don't know if it's proper (for opening an issue like this). Sorry for bothering, I just want to provide my personal opinion.
various frameworks support multiple .env files (using naming conventions) to support multiple target destinations
You have a step "Make Changes." (here), where you say this:
git add
git commit -a
Why:
git commit -a will start an editor which lets you separate the subject from the body. Read more about it in section 1.3.
However, this will not work. When someone runs git add
, it will output the following:
โ git add
Nothing specified, nothing added.
Maybe you wanted to say 'git add .'?
Also, git commit -a
does NOT mean "start an editor". It means the following (straight from man git-commit
):
-a, --all
Tell the command to automatically stage files that have been
modified and deleted, but new files you have not told Git about
are not affected.
If you want, I can make some changes to this and shoot you a PR. ๐
This would be a good addition to the guide as they encourage a good commit policy and push you towards implementing continuous integration workflows.
There are a few good tools that make git hooks easy such as husky, among others.
If approved, I can start working on adding this to the guide. Let me know your thoughts.
Cheers! โค๏ธ
Because why not :)
This formatting is a bit confusing. It looks as though, e.g., you are suggesting that the user do ls | npm Documentation
(i.e., UNIX ls
command piped to npm Documentation
). It also won't be clear to new users that one must prepend the npm
command. I recommend changing this formatting to formatted code npm ls
with a "documentation" link after and clearly differentiated from the code example.
As the screenshot I have added point out, the whole of the content uses a declarative and instructive verbiage while explaining concepts whereas a few of the headings in the Coding Style
sections deviate from the rest in a way that they are more suggestive or in some cases not instructive but informative.
My suggestion would be to make it a little bit consistent with the rest of the headings while still keeping it's original suggestive meaning.
also I would love to work on the same as it seems like an easy fix.
Having a section on issues best practices, particularly as it relates to development, would be useful. E.g.:
... something like that anyway? I personally favor Github Issues, but this section could be agnostic (or have separate issue tracker carveouts?)
Hello,
Nice initiative !
However, a set of rules is never well followed when one does not fully understand why the rules were enacted. It also helps to adhere to a rule when one knows what can occur if the rule is ignored.
I think that along with the list of rules, the reasons why each of them was written this way should also be detailed (through hyperlinks to not clutter the rules list itself). Pointing to issues that occurred when a rule was not followed would also help.
The Link : https://medium.com/@kentcdodds/why-semver-ranges-are-literally-the-worst-817cdcb09277
is broken
Line 259 in 37a29d5
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.