-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add links to npm packages in package.json file view #29344
base: main
Are you sure you want to change the base?
Conversation
c01247c
to
888e9af
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm…
I'm simultaneously against and in favor of adding this special handling.
What it will most likely lead to is a barrage of other issues requesting special handling for other files as well.
However, I can also see why it is useful.
Is there perhaps a way to make this approach extensible, so that an admin can add scripts themselves to decide which files should receive special handling?
That way, we can then tell people wanting additional handling to do it themselves.
Yeah it's kind of borderline. GitLab has this as well, FWIW, example.
Admins can already add custom scripts which would be able to do the same. |
I could certainly see this being extended to support more file types like go.mod, cargo.toml, pyproject.toml, requirements.txt, imports in go files, imports in js, etc. All easy to parse and alter. Kind of like what popular (but currently broken) github extension https://github.com/OctoLinker/OctoLinker did. |
Extract from go-gitea/gitea#29344. With this class it's possible to have links that don't color on hover. It will be useful for go-gitea/gitea#29429. (cherry picked from commit ffeaf2d0bd6c99c486aa7869779bb9ceb0aedad6)
* origin/main: (332 commits) Refactor external URL detection (go-gitea#29973) Refactor repo header/list (go-gitea#29969) Fix various loading states, remove `.loading` class (go-gitea#29920) Update register application URL for GitLab (go-gitea#29959) Refactor StringsToInt64s (go-gitea#29967) Switch to happy-dom for testing (go-gitea#29948) Performance improvements for pull request list page (go-gitea#29900) Refactor URL detection (go-gitea#29960) Solving the issue of UI disruption when the review is deleted without refreshing (go-gitea#29951) Fix JS error and improve error message styles (go-gitea#29963) Fix the bug that user may logout if he switch pages too fast (go-gitea#29962) Cancel previous runs of the same PR automatically (go-gitea#29961) Exclude `routers/private/tests` from air (go-gitea#29949) Remove codecov badge (go-gitea#29950) Misc color tweaks (go-gitea#29943) Fix and rewrite markup anchor processing (go-gitea#29931) Remove fomantic grid module (go-gitea#29894) Add background to dashboard navbar, fix missing padding (go-gitea#29940) Prevent layout shift in `<overflow-menu>` items (go-gitea#29831) Fix loadOneBranch panic (go-gitea#29938) ...
Restructured into new file |
@wxiaoguang let me know if I bother you too much with those review request 😆 |
} | ||
|
||
// match chroma NameTag token to detect JSON object keys | ||
for (const el of document.querySelectorAll('.code-inner .nt')) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is really fragile, it doesn't seem suitable to be done on frontend.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's the best frontend can do, and I don't think chroma would ever break it and even if it does, it will be graceful.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's not right to let frontend do: the JS code only sees the rendered content, and it heavily depends on Chroma behavior.
I am sure there could be a stable backend solution: fully tested and fully controllable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll not be doing that in backend and I think doing it in backend would massively limit future similar "postprocessing".
Doing these file processings in frontend enables to do more that what the backend could do with only HTML rendering. In this case it's possible to do in backend but on other more advanced cases like, frontend side will be required so I prefer to keep it in frontend only.
Take for example GitHub's code view. All the features there like "go to function" and symbol definitions are pure frontend features in React. The backend is just a dumb server of the content and I think that's very preferable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll personally not be doing that in backend and I think doing it in backend would massively limit future similar processings.
I do not think it would limit any future processings. Instead, backend could handle all future processings better than frontend.
For example, if it needs to handle maven XML, in frontend, you need a lot of tricks to to handle the rendered XML-HTML content. But in backend, it sees the clear origin content and could add links clearly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have fun implementing a VSCode-like code view in backend 😆. I think these features definitely need to be in frontend and in fact can only be done there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
General talking about "frontend" and "backend" is not clear for this case. Let's abstract the logic:
- origin content (text) -> highlight (get HTML) -> split to lines (HTML-line slice) -> output to page content
So the question is: add the links between which steps?
My "backend" proposal:
- origin content (text) -> highlight AND/OR add links (get HTML) -> split to lines (HTML-line slice) -> output to page content
You "frontend" proposal:
- origin content (text) -> highlight (get HTML) -> split to lines (HTML-line slice) -> output to page content -> use JS to parse the rendered HTML to add links
VSCode: VSCode has a well-designed plugin system, I haven't really looked into it, so I don't know at which step it could add links. My intuition tells me it is very unlikely to do it at the last step (eg: parse the rendered content). If I was a VSCode developer, I would do it like this:
- origin content (text) -> parse (structured tree) -> plugin processing (add links) -> highlight (get HTML) -> output to editor
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adding only links or any other HTML content can be done in backend but my point is that if the post-processing goes beyong HTML modification, like for example a JSON "block folding" feature, this has do be done in JS and then it's better if all such post-processing code is in frontend (JS) and not split between backend and frontend.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, if we decide to render code using React or Vue, it will be much easier to migrate the JS code than to migrate it from Go.
Maybe we need a whole design resolution but not a case looks like hacky. |
I think doing it in frontend is reasonable. Backend would be better of course, but I'll not be willing to it in backend personally. |
I mean maybe we should introduce a syntax analysis mechanism that supports LSP. So that not only this kind of file but all kinds of files can have references and jumps. |
Yes of course some intelligent view like GitHub has would be great long-term, but this likely requires persistent subprocesses for the LSP servers and integration against their protocol likely using websocket. |
When viewing
package.json
, this will add links to npmjs.com for all dependencies:Two caveats: