Comments (19)
Side note: I don't think standard
will get a lot of approval here, primarily due to the absence of semicolons and the presence of spaces after function names (had to deal with that yesterday when patching pino). I would prefer to stay close to the conventions we are using in Node.js core, considering that the majority of devs and users are probably core developers.
from automation.
This is a valid point, but all these tools already need to work consistently on the same project (Node Core).
Following this, if we are to reduce complexity (for others), we should in effect try to bundle them in one loosely coupled super tool (while still allowing them to be used separately), and thus, having one coding standard form all of them really is necessary IMHO.
But I acknowledge that I may be thinking that way because I primarily come from PHP and specifically from Symfony, where standards are of paramount importance. So I'm totally open to suggestions.
I just think we would gain from a bit of standardization, while we do need to go progressively and wait for the initial setup to be stabilized a bit.
from automation.
Even though code style is off topic in regards to the issue title, I do want to jump in early and propose using standard or similar like we do on the nodejs.org and github-bot codebases before anyone makes an effort in creating the "perfect eslint config" across many projects. I'm personally a big fan of not having to use time maintaining or discussing code style.
If that's very controversial, I think creating a dedicated issue for code style is better than going waaay off topic in this issue.
from automation.
node core does already have an eslint config, so we could just use that (or even extract it into a separate module).
๐ for extracting to a separate module. We could then use it in other foundation projects such as node-report (see nodejs/node-report#44).
from automation.
Are we already duplicating a lot? I didn't have a look at all the tools we are currently using, but I also did not come across a lot of duplicate files / contents yet. Duplicate APIs can always be extracted into npm packages, we don't even need to keep our dependencies within the org. GraphQL queries and fixtures are usually specific to an application, and those can still be extracted into npm packages if necessary. .editorconfig
files are usually either very simple or very specific, plus they rarely ever change within a project. We could consider shared ESLint configuration files, but depending on who authored a package, the styles may differ a lot... Especially when it comes to custom rules.
Again, I don't know all of our automation / tooling code, so my impression might be wrong here.
from automation.
But, it could be a good practice to unify and apply the same coding style.. I dont't know...
Right now, we aren't duplicating a lot, but I think we need to look to the future and stablish some code and folder structure standards with the intention of make all the projects more readable to new collaborators.
Imagine this: in a hypothetical future we have code standards and 100 projects and we decide to change some ESLint rules, or indentation size or whatever. That means changing all the .eslintrc
in all the repositories.
Maybe I'm rumbling too much. It's just an idea.
from automation.
Although I'm all for some sort of "config standard" for all automation projects, I'd suggest we wait for Lerna and the monorepo to be properly set. We will then have a better vision of what we have, and what we need, on the deployment/release/config side of things.
Some of the tools we maintain or plan to maintain (like node-core-utils ) already check for standard configuration/commit messages, and standardization is in the core ADN of NodeJS I'd say.
But right now, I feel we are still in the phase of bootstrapping things, building a repo, and defining what to work on, and we don't know yet if it doesn't already exist in a form or another.
I don't know if I'm clear enough, sorry, it's late here and I'm french (irony).
Bottom line, tl;dr:
Great idea, but let's wait and see when monorepo's here. Let's first define our collaboration guidelines.
from automation.
@Tiriel Yes, you are being clear, but precisely for that reason I think we should stablish it ASAP.
PS: I'm spanish, we're neighbors ๐
from automation.
from automation.
@MylesBorins there's a general discussion about automation projects at #1, I've got a PR open at #9 to move over the first tool and setup lerna
from automation.
@MylesBorins there's a general discussion about automation projects at #1, I've got a PR open at #9 to move over the first tool and setup lerna
Yes I think this issue is similar to those discussions.
I like the idea of a monorepo for all the small utilities. I suggest we move on to #9 because there is already some work being done there. People can put a red corss if they don't like it, or discuss/put a green check if they do
from automation.
Oh, on a second thought, we should probably have a issue dedicated to the monorepo discussion. We have not decided if we want a monorepo, is it going to happen in this repo or another repo (i.e. reserve this repo for discussion and documentations), so I think we can leave #9 alone for the moment.
from automation.
Monorepo discussion thread opened in #12
from automation.
Just to get back on the initial discussion then, it does seem logical for an automation team to have standards and automation tools...
I'm just not fond of doing everything at the same time, it feels like we may cut corner by doing so. But I'm with you on the need to do it on a very short notice.
from automation.
in a hypothetical future we have code standards and 100 projects and we decide to change some ESLint rules, or indentation size or whatever. That means changing all the
.eslintrc
in all the repositories.
Keep in mind that the automation toolset is supposed to aid the development of the Node.js core, so creating dozens of automation-related projects maintained by the org is probably a bit far-fetched.
By the way, if you change a rule in the ESLint configuration and automatically sync it with all projects, you will also need to change the code in all of those projects, so you still need to manually work on every single project.
We can create repos all we want, but introducing additional dependencies (e.g. shared configs, APIs etc) comes with additional complexity, and complexity is something we should try to avoid.
I am not opposed to having a shared repository if it turns out to be necessary, but preemptively creating one does not seem like a good idea to me.
from automation.
I don't think this is properly off-topic, since code-styling is part of what OP proposes via eslint files.
I do feel that keeping to a well established standard will be simpler. But I have to say, I too prefer using semi-colons, from time to time :)
And since these tools will be used in conjunction with core, keeping close to the styles used there seem a good idea.
from automation.
Maybe we could create another thread to define coding standars, or otherwise, use the Node.js ones.
from automation.
Maybe we could create another thread to define coding standards, or otherwise, use the Node.js ones.
If the idea is to make tools for Node core, using the style Node core uses would make sense. I think the idea of standard is great, but (ironically) find the no-semicolons and spaces after function names causes way too much churn when converting projects.
before anyone makes an effort in creating the "perfect eslint config" across many projects.
node core does already have an eslint config, so we could just use that (or even extract it into a separate module).
To get back to the original issue, I think if we go with a monorepo approach, then a separate repo won't be necessary, and it seems like there is general agreement that a monorepo would be a good idea. So I'd suggest holding off on that.
from automation.
Unarchived this repo so I could close all the PRs and issues. Will re-archive when I'm done.
from automation.
Related Issues (20)
- Should Automation take ownership of make-node-meeting? HOT 6
- Proposing to form a monorepo HOT 14
- Can we automate appending changelogs to a release HOT 3
- Side effect: Working with Build WG to change description on Nodejs.org ? HOT 9
- CitGM testing Node-Core-Utils? HOT 10
- Include collaborators/team members in the README? HOT 8
- Idea: A twitter bot to thank new contributors HOT 4
- An app for managing bans HOT 8
- greenkeeper-like feature for ncu-team HOT 5
- Use ncu-team in create-node-meeting-artifacts HOT 1
- avoid CI typos HOT 6
- Tool for generating/maintaining/auditing CODEOWNER file HOT 12
- doc REPLACEME linter/fixer HOT 3
- Commit Queue HOT 8
- explore k8s prow as a way to automate stuff in github HOT 4
- Github team management (reply here if you want to join) HOT 33
- Node.js clone repo for testing HOT 6
- Brigade HOT 3
- Repo and npm accesses of related projects HOT 13
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ๐๐๐
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google โค๏ธ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from automation.