Improve maintianbility #68
Comments
|
Im against complexity in my projects, I always favour simplicity over functionalities. 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 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. |
|
per prettier/prettier#4125 it seems bracket is needed to avoid single line |
@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
See the comments on the following issue for more details on this:
A fairly common choice for this these days is
These days I would probably suggest GitHub actions for this instead:
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:
Semi-related: |
|
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. |
@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.
@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 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.
@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. |
|
Always happy to have help, feel free to do any PR. |
|
In response to 0xdevalias:
Doesnt have to be pushed into a utils folder, as long as it is optinal to use.
We are sharing thoughts, all ideas are welcome.
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 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.
@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.
@jagenjo 👌🏻
@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. |
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.
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.
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.
I dont have good experiences with bloated work flows. I love JS for its simplicity. |
There is many tools can be used in a open source project
I suggest to use these tools to improve code maintianbility:
for style check
for code formatting
for generate changelog from git commit messages
for automatic build any deploy
for host project home page
for discover matianbility isssues
replace eslint with tslint if choose to use typescript
The text was updated successfully, but these errors were encountered: