Source Code Documentation #259
Comments
|
This would be great, I was also thinking it would be great if some folks put together walkthroughs of how to change settings, move things about. I was thinking about making some showing how I debug some issues and fix them and then push the changes to github.. Maybe at some point I will still do that.. Just a case of finding time ;\ -----Original Message----- Is there any value in creating something which better explains how etherpad-lite works from a developer standpoint? There is very little documentation on the etherpad-lite source code which mean trying to understand how it works can be very hard and tends to involve (alteast for me) lots of break points and moving around the call stack to try and understand how everything happens. The node.js server code is easier to understand, but the ACE editor is difficult to say the least. It would be nice to hear from other people who have been trying to understand the code to know if they feel the same way. I know people have differing opinions on source code documentation, for example a friend once said to me if you need to document your source code you need to rewrite it because it is not clear. I have some spare time at the moment so I was planning to read through and get a much better understanding of how etherpad-lite works and as I do so I will make notes. Would it be a good idea if I made notes with a view to creating documentation which could be published or even just something less compressive that could serve as an introduction to the code base for new developers? Reply to this email directly or view it on GitHub: |
|
+1 |
|
I completely aggree and can help with it since i'm starting to understand well the rendering/editing code |
|
Adding Documentation in the source code is always appreciated. I think its also a good idea to add a "how to debug" page to the wiki (instead of improving the section in the readme all the time) |
|
Just an update on this I have been reading and getting a better understanding on how everything works on the editor side of things. I will try and writing something that explains the structure and post it and we will see if anyone thinks it is helpful. And even if is is not it will have helped me. Also as I am reading the comments a lot I think I will make a note of the typos in the comments and at the end submit a pull to fix them. For example there have been a few times I thought Yoda wrote them: "if we haven't recieved the clientVars yet, then this message should it be" |
|
Jonathon. Did you see the video I made? Jonathon Smith reply@reply.github.com wrote: Just an update on this I have been reading and getting a better understanding on how everything works on the editor side of things. I will try and writing something that explains the structure and post it and we will see if anyone thinks it is helpful. And even if is is not it will have helped me. Also as I am reading the comments a lot I think I will make a note of the typos in the comments and at the end submit a pull to fix them. For example there have been a few times I thought Yoda wrote them: "if we haven't recieved the clientVars yet, then this message should it be" Reply to this email directly or view it on GitHub: |
|
May the Force be with you! ;) |
|
Hehe Peter 'Pita' Martischka reply@reply.github.com wrote: May the Force be with you! ;) Reply to this email directly or view it on GitHub: |
|
https://github.com/ether/etherpad-lite/wiki is your friend. |
|
Hi JohnMcLear, I couldn't find the link to the video you mentioned above. Please share it, it will be a great help to me to debug how it is working and how can I tweak things as per my requirement. |
This upgrade should be backward compatible, but still suffers form major vulnerabilities in its https-proxy-agent transitive dependency (see https://www.npmjs.com/advisories/1184). Changelog: - https://github.com/npm/cli/releases 6.12.0 (2019-10-08): Now npm ci runs prepare scripts for git dependencies, and respects the --no-optional argument. Warnings for engine mismatches are printed again. Various other fixes and cleanups. BUG FIXES 890b245dc #252 ci: add dirPacker to options (@claudiahdz) f3299acd0 #257 npm.community#4792 warn message on engine mismatch (@ruyadorno) bbc92fb8f #259 npm.community#10288 Fix figgyPudding error in npm token (@benblank) 70f54dcb5 #241 doctor: Make OK more consistent (@gemal) FEATURES ed993a29c #249 Add CI environment variables to user-agent (@isaacs) f6b0459a4 #248 Add option to save package-lock without formatting Adds a new config --format-package-lock, which defaults to true. (@bl00mber) DEPENDENCIES 0ca063c5d npm-lifecycle@3.1.4: fix: filter functions and undefined out of makeEnv (@isaacs) 5df6b0ea2 libcipm@4.0.4: fix: pack git directories properly (@claudiahdz) respect no-optional argument (@cruzdanilo) 7e04f728c tar@4.4.12 5c380e5a3 stringify-package@1.0.1 (@isaacs) 62f2ca692 node-gyp@5.0.5 (@isaacs) 0ff0ea47a npm-install-checks@3.0.2 (@isaacs) f46edae94 hosted-git-info@2.8.5 (@isaacs) TESTING 44a2b036b #262 fix root-ownership race conditions in meta-test (@isaacs) 6.11.3 (2019-09-03): Fix npm ci regressions and npm outdated depth. BUG FIXES 235ed1d28 #239 Don't override user specified depth in outdated. Restores ability to update packages using --depth as suggested by npm audit. (@G-Rath) 1fafb5151 #242 npm.community#9586 Revert "install: do not descend into directory deps' child modules" (@isaacs) cebf542e6 #243 npm.community#9720 ci: pass appropriate configs for file/dir modes (@isaacs) DEPENDENCIES e5fbb7ed1 read-cmd-shim@1.0.4 (@claudiahdz) 23ce65616 npm-pick-manifest@3.0.2 (@claudiahdz) 6.11.2 (2019-08-22): Fix a recent Windows regression, and two long-standing Windows bugs. Also, get CI running on Windows, so these things are less likely in the future. DEPENDENCIES 9778a1b87 cmd-shim@3.0.3: Fix regression where shims fail to preserve exit code (@isaacs) bf93e91d8 npm-package-arg@6.1.1: Properly handle git+file: urls on Windows when a drive letter is included. (@isaacs) BUGFIXES 6cc4cc66f escape args properly on Windows Bash Despite being bash, Node.js running on windows git mingw bash still executes child processes using cmd.exe. As a result, arguments in this environment need to be escaped in the style of cmd.exe, not bash. (@isaacs) TESTS 291aba7b8 make tests pass on Windows (@isaacs) fea3a023a travis: run tests on Windows as well (@isaacs) 6.11.1 (2019-08-20): Fix a regression for windows command shim syntax. 37db29647 cmd-shim@3.0.2 (@isaacs) v6.11.0 (2019-08-20): A few meaty bugfixes, and introducing peerDependenciesMeta. FEATURES a12341088 #224 Implements peerDependenciesMeta (@arcanis) 2f3b79bba #234 add new forbidden 403 error code (@claudiahdz) BUGFIXES 24acc9fc8 and 45772af0d #217 npm.community#8863 npm.community#9327 do not descend into directory deps' child modules, fix shrinkwrap files that inappropriately list child nodes of symlink packages (@isaacs and @salomvary) 50cfe113d #229 fixed typo in semver doc (@gall0ws) e8fb2a1bd #231 Fix spelling mistakes in CHANGELOG-3.md (@XhmikosR) 769d2e057 npm/uid-number#7 Better error on invalid --user/--group configs. This addresses the issue when people fail to install binary packages on Docker and other environments where there is no 'nobody' user. (@isaacs) 8b43c9624 nodejs/node#28987 npm.community#6032 npm.community#6658 npm.community#6069 npm.community#9323 Fix the regression where random config values in a .npmrc file are not passed to lifecycle scripts, breaking build processes which rely on them. (@isaacs) 8b85eaa47 save files with inferred ownership rather than relying on SUDO_UID and SUDO_GID. (@isaacs) b7f6e5f02 Infer ownership of shrinkwrap files (@isaacs) 54b095d77 #235 Add spec to dist-tag remove function (@theberbie) DEPENDENCIES dc8f9e52f pacote@9.5.7: Infer the ownership of all unpacked files in node_modules, so that we never have user-owned files in root-owned folders, or root-owned files in user-owned folders. (@isaacs) bb33940c3 cmd-shim@3.0.0: 9c93ac3 #2 npm#3380 Handle environment variables properly (@basbossink) 2d277f8 #25 #36 #35 Fix 'no shebang' case by always providing $basedir in shell script (@igorklopov) adaf20b #26 Fix $* causing an error when arguments contain parentheses (@satazor) 49f0c13 #30 Fix paths for MSYS/MINGW bash (@dscho) 51a8af3 #34 Add proper support for PowerShell (@ExE-Boss) 4c37e04 #10 Work around quoted batch file names (@isaacs) a4e279544 npm-lifecycle@3.1.3 (@isaacs): fail properly if uid-number raises an error 7086a1809 libcipm@4.0.3 (@isaacs) 8845141f9 read-package-json@2.1.0 (@isaacs) 51c028215 bin-links@1.1.3 (@isaacs) 534a5548c read-cmd-shim@1.0.3 (@isaacs) 3038f2fd5 gentle-fs@2.2.1 (@isaacs) a609a1648 graceful-fs@4.2.2 (@isaacs) f0346f754 cacache@12.0.3 (@isaacs) ca9c615c8 npm-pick-manifest@3.0.0 (@isaacs) b417affbf pacote@9.5.8 (@isaacs) TESTS b6df0913c #228 Proper handing of /usr/bin/node lifecycle-path test (@olivr70) aaf98e88c npm-registry-mock@1.3.0 (@isaacs)
Is there any value in creating something which better explains how etherpad-lite works from a developer standpoint? There is very little documentation on the etherpad-lite source code which mean trying to understand how it works can be very hard and tends to involve (alteast for me) lots of break points and moving around the call stack to try and understand how everything happens. The node.js server code is easier to understand, but the ACE editor is difficult to say the least.
It would be nice to hear from other people who have been trying to understand the code to know if they feel the same way.
I know people have differing opinions on source code documentation, for example a friend once said to me if you need to document your source code you need to rewrite it because it is not clear. I have some spare time at the moment so I was planning to read through and get a much better understanding of how etherpad-lite works and as I do so I will make notes. Would it be a good idea if I made notes with a view to creating documentation which could be published or even just something less compressive that could serve as an introduction to the code base for new developers?
The text was updated successfully, but these errors were encountered: