litegraph.js
litegraph.js copied to clipboard
jagenjo
Improve maintianbility
There is many tools can be used in a open source project I suggest to use these tools to improve code maintianbility:
- linter: eslint for style check
- formatter: prettier + lint-staged for code formatting
- changelog: standard-version for generate changelog from git commit messages
- CI: circle-ci / travis-ci for automatic build any deploy
- web hosting: github pages for host project home page
- core review: codeclimate / lgtm for discover matianbility isssues
- static type check: typescript replace eslint with tslint if choose to use typescript
Im against complexity in my projects, I always favour simplicity over functionalities. Thats why Im against of typescript, webpack, etc. Even the npm build wasnt added by me, Im just happy with a simple python script of 10 lines.
If you want to add extra optional stuff in the utils folder, Im glad to accept it, but anything added there should always be optional and not enforced to developers.
Let me know your thoughts.
Almost all these tools can be setup by a npm install command and no extra effort for contributor
I see some method name are camelCase and some are snake_case in this project, that's why i suggest eslint and prettier
I also suprised when i have to install java runtime to develop a javasript project, webpack can solve this
Writing a typescript definition and have to look at source code because the outdated doc, and typescript can gives you a always updated typedoc
And a 8000 lines file or a 100 lines function is hard to read for me, that's why code reivews tools needed
PS: I guess you are trying to do javascript in a pythonic way, but the users of a js library will be always more familiar with javascript tools
you do not have to install java unless you want to minify it, even if you want to develop you do not have to launch any command, because the demo editor includes the JSs files separately, so it is super-easy to develop, just modify file and reload.
But I understand your concerns and your suggestions are good, so if you want to create or improve the npm pipeline, feel free, I will add it.
About the documentation, there is this documentation but it could be greatly improved.
About the gitpage, it is a great idea, I will work on that.
Hey @NateScarlet just wanted to thank you for your help, it is nice that somebody besides me pushes this project, but please, do not launch the process that "beauytifies" the code again, most of the changes are against my way of working, specially one line ifs, and ifs where the condition touches the parenthesis.
My eye-sight is not so good and having all cramped in one line makes it hard for me to read it. Can that be configured somehow? otherwise I have to go line by line fixing it.
per https://github.com/prettier/prettier/issues/4125 it seems bracket is needed to avoid single line if by prettier
but eslint seems has a rule match your need: https://eslint.org/docs/rules/curly
i will try configure it with eslint
Im against complexity in my projects, I always favour simplicity over functionalities. Thats why Im against of typescript, webpack, etc.
If you want to add extra optional stuff in the utils folder, Im glad to accept it, but anything added there should always be optional and not enforced to developers.
But I understand your concerns and your suggestions are good, so if you want to create or improve the npm pipeline, feel free, I will add it.
@jagenjo Curious if you're still against these 'fairly standard JS tooling' sort of changes being made in a 'direct' way (eg. not just hidden away in utils), as it would make this project a lot easier for others to be able to understand and jump into contributing on; and generally can largely be set up in a way that can just be handled somewhat 'automatically behind the scenes' without needing to consciously remember what to run/when/etc.
formatter: prettier + lint-staged for code formatting
See the comments on the following issue for more details on this:
- https://github.com/jagenjo/litegraph.js/issues/429#issuecomment-1837746891
changelog: standard-version for generate changelog from git commit messages
A fairly common choice for this these days is release-please (and the related GitHub action)
- https://github.com/googleapis/release-please
-
Release Please automates CHANGELOG generation, the creation of GitHub releases, and version bumps for your projects.
It does so by parsing your git history, looking for Conventional Commit messages, and creating release PRs.
-
- https://github.com/google-github-actions/release-please-action
-
Automate releases with Conventional Commit Messages.
-
These days I would probably suggest GitHub actions for this instead:
- https://github.com/features/actions
core review: codeclimate / lgtm for discover matianbility isssues
This one you could probably skip/hold off on for a while, it's not quite as standard as a lot of the other tools mentioned here, and in my experience, can sometimes lead to more noise than helpfulness unless tuned properly.
For bundling/related you could look at tools such as:
- https://github.com/egoist/tsup
-
Bundle your TypeScript library with no config, powered by esbuild.
-
Semi-related:
- https://github.com/jagenjo/litegraph.js/issues/137
- https://github.com/jagenjo/litegraph.js/issues/183
- https://github.com/jagenjo/litegraph.js/issues/199
- https://github.com/jagenjo/litegraph.js/issues/306
- https://github.com/jagenjo/litegraph.js/issues/429
yes, im still against, and I use webpack at work every day.
But I like simplicity, and I insist, if somebody want to propose some extra tooling as long as it is optional Im happy to accept it. That means I can code in a old-fashion way and everything works, but there is a script I can execute to lint/check errors/update bindings to ts, etc.
Feel free to comment your opinions.
im still against, and I use webpack at work every day.
@jagenjo Ha, fair. If I had to deal with webpack every day I might be as well :p There are some pretty nice options that abstract a lot of that pain away these days, and that can run a lot faster than webpack too.
if somebody want to propose some extra tooling as long as it is optional
@jagenjo Depending on the specific tooling, I think you'll find that a lot of people (potentially biased, since this is my personal opinion) who might otherwise have been interested in contributing these sorts of enhancements will be turned off by the idea of it being an optional thing hidden away and pushed to the side in a util folder.
IMO, one of the things that makes a lot of these tools so useful is that they are embedded in the workflow/run by default; thereby enforcing those standards along the way.
Obviously what gets used (or not used) with this project is ultimately up to you as the owner, so I'm definitely not trying to say you absolutely 'have to' do any of this; though hopefully the 'outside perspective' is helpful at least.
That means I can code in a old-fashion way and everything works
@jagenjo If you're open to sharing, I'm curious what aspects of the suggested modern tooling specifically 'gets in the way' of you doing things in an 'old fashioned way'? I wonder if there might be a middle-ground option that isn't purely 'the old way', but also doesn't needlessly 'get in the way' of your process and overcomplicate things for you?
Just to add an additional perspective: much of the suggested tooling makes it easier for downstream consumers of this library to actually consume it. I've spent about 12 hours the last few days just trying to integrate litegraph into my React project. Most of the issues resolved around getting the package into the project (can't use plain-ole script tags, gotta use npm). I bounced around various NPM packages trying to find the most updated one, I created forks trying to combine the features of the editor into the NPM package since it wasn't included, etc, etc, etc. This project is one of the coolest I've ever used, but was by far (no competition) the most painful to actually get set up in my project.
Completely understand the perspective that the Javascript tooling ecosystem today is far too complicated, however, I think many of the suggested tools (especially CI) are targeted at consumers just as much as contributors.
On that note, I've spent quite a bit of time in Github Actions over the years. I'm happy to lend a hand in setting up CI so that changes to this project are automatically built properly and pushed to NPM.
In response to 0xdevalias:
There are some pretty nice options that abstract a lot of that pain away these days, and that can run a lot faster than webpack too. As I always say, make a proposal and it will be considered.
@jagenjo Depending on the specific tooling, I think you'll find that a lot of people (potentially biased, since this is my personal opinion) who might otherwise have been interested in contributing these sorts of enhancements will be turned off by the idea of it being an optional thing hidden away and pushed to the side in a
utilfolder.
Doesnt have to be pushed into a utils folder, as long as it is optinal to use.
Obviously what gets used (or not used) with this project is ultimately up to you as the owner, so I'm definitely not trying to say you absolutely 'have to' do any of this; though hopefully the 'outside perspective' is helpful at least.
We are sharing thoughts, all ideas are welcome.
@jagenjo If you're open to sharing, I'm curious what aspects of the suggested modern tooling specifically 'gets in the way' of you doing things in an 'old fashioned way'? I wonder if there might be a middle-ground option that isn't purely 'the old way', but also doesn't needlessly 'get in the way' of your process and overcomplicate things for you?
I like to edit a file, refresh and be able to see the changes instantly in my browser. Without having to launch any process in the background.
As I always say, make a proposal and it will be considered.
@jagenjo So far, your answers to my questions (and others) have basically given the impression that there is an impasse with anything I would propose, and your desired way of working.
Doesnt have to be pushed into a utils folder, as long as it is optinal to use.
@jagenjo I was using "pushed away into a utils folder" conceptually rather than literally. The changes that would likely produce the most value here would by definition not be able to be adopted optionally. They tend to be a "you use it or you don't" type thing.
We are sharing thoughts, all ideas are welcome.
@jagenjo 👌🏻
I like to edit a file, refresh and be able to see the changes instantly in my browser. Without having to launch any process in the background.
@jagenjo I can definitely understand and agree with most of that; though I wonder what your specific issue is with the last caveat of "Without having to launch any process in the background"?
Is it a performance/overhead thing (eg. you've found your dev machine runs it too slowly/etc), or just an idealogical one?
For me, there have definitely been projects and poorly tuned tool setups in the past where it had a noticeable and annoying impact on my dev productivity; but that is definitely the exception rather than the norm, particularly with some of the modern tooling.
@0xdevalias
@jagenjo So far, your answers to my questions (and others) have basically given the impression that there is an impasse with anything I would propose, and your desired way of working.
Sorry If I give that impression, sometimes I have little time to answer and I cant analyze the answer completly, maybe because it is vague or it is spread in different comments or maybe I remember answering that some time ago. Anyway, any PR is always considered.
@jagenjo I was using "pushed away into a utils folder" conceptually rather than literally. The changes that would likely produce the most value here would by definition not be able to be adopted optionally. They tend to be a "you use it or you don't" type thing.
Then if it is not optionally (like having to depend on thirt-party software forever I would say no, as it makes everything harder to maintain by a non-expert like me.
@jagenjo I can definitely understand and agree with most of that; though I wonder what your specific issue is with the last caveat of "Without having to launch any process in the background"?
I support many project in my remote machine, I dont want to have to launch lots of processes to support them all, as im switching constantly from project to project while I develop. Also because it is way faster than having to wait to some process to catch-on changes, and regenerate the JS. Im already suffering that at my work place.
Is it a performance/overhead thing (eg. you've found your dev machine runs it too slowly/etc), or just an idealogical one?
For me, there have definitely been projects and poorly tuned tool setups in the past where it had a noticeable and annoying impact on my dev productivity; but that is definitely the exception rather than the norm, particularly with some of the modern tooling.
I dont have good experiences with bloated work flows. I love JS for its simplicity.