Create a new extension with only tsEssentialPlugins.patchOutline

[Magnuti]

Great package! But imo it does too much. I was looking for sticky headers in .jsx and .tsx files in VS Code and I came across this extension from this Reddit post.

Does the package work as expected?

• Yes

Did I disable everything except the tsEssentialPlugins.patchOutline option

• Yes

I am very fond of VS Code extensions that does one thing, and that does that one thing perfectly.

I have no use for the other features, it just clutters the extension and pollutes my workspace. If you split the sticky header feature into its own extension you will maybe get more downloads and more positive reviews.

[zardoy]

thank you so much for the review here (even though that reddit post is very old).

I am very fond of VS Code extensions that does one thing, and that does that one thing perfectly.

Everyone wants this. And I wanted to do this since very first release, but it was difficult to name and create an icon for each extension. Also it wasn't clear how to split these features into different extensions (for example now I have more than 100 features). On the other hand I also wanted to leave everything in this main extension as-is, and publish a few additional extensions with some functionality extracted from this extension. I understand that extensions like Pretty TypeScript Errors also do only one thing and everyone loves that.
But I don't think i will get more bandwidth if i do this. Also right now i would need to rewrite whole infra to enable on-demand extensions publishing...

I have no use for the other features, it just clutters the extension and pollutes my workspace.

This one is unclear to me, don't you mind explaining? I honestly think things from this extension should be available out-of-the-box (such as improved autocomplete ...). Don't you mind sharing what you didn't like?

[Magnuti]

It's not that I don't like the other features @zardoy, it's just that I don't need them. As the lightweight editor VS Code is, extensions should also be "lightweight".
For example

• I already use GitHub copilot so I don't need better auto completion.
• I already use ESLint so my imports are already sorted and auto imported

Don't misunderstand me, this issue was not meant to be a critic on your extension! I am just reluctant on adding extensions that can possibly change the behavior of my editor, and that adds side effects I don't know about without examining every feature of the extension.

[zardoy]

it's just that I don't need them

I try to remove redundant features (or at least keep them disabled). If you feel some features are completely useless please let me know. I also use copilot with extended line completions and must admit it now makes me to use actual suggestion widget just in 1 of 10 cases. But copilot still cant see method signatures from not popular packages and some global variables. If you feel that some features make experience worse, please let me know.

As the lightweight editor VS Code is, extensions should also be "lightweight"

I generally agree with you but I also think its good when you have the best possible experience out of the box (provide best defaults, but make configurable). If you feel that some features slows you down, also please let me know about that!

I already use ESLint so my imports are already sorted and auto imported

I also use eslint with thousands of rules for insane static analysis (even in this repo), that's why this extensions doesn't contribute any hints for your code.

I am just reluctant on adding extensions that can possibly change the behavior of my editor, and that adds side effects I don't know about without examining every feature of the extension.

Ok I see, also you're not the first one, even my collaborator already told me this hundred of times and we wanted to build an interactive playground to solve it, but unfortunately I don't work on this codebase much anymore.

[Magnuti]

Thank you for your clarification and quick response @zardoy! I'll close this issue as its just a personal rant from my POV now.

Would you be fine with me forking the repo and creating my own extension with only the patchOutline functionality? Giving credits to you, the authors, of course!

[zardoy]

I would recommend you creating a new repo for a new VSCode extension and then reusing this plugin as package from npm instead of forking. This will result in much cleaner solution imo. I will publish this plugin to npm asap

[zardoy]

published https://www.npmjs.com/package/typescript-essential-plugins

you can do somehting like this:

const getNavTreeItems = require('./typescript/build/getPatchedNavTree.js').getNavTreeItems

// see typing & usage
// languageService, languageServiceHost from plugin wrapper, filename from ls proxy
getNavTreeItems(languageService, languageServiceHost, fileName, {arraysTuplesNumberedItems: true,})

I recommend using it over forking whole extension repo for this lightweight functionality

[Magnuti]

Thank you for the clarification!

[devYonz]

This didn't work well for me in react-native -- I resorted to the default one


Its either only JSX or only code :(

[zardoy]

I'm sorry, I didn't get it 😔

[devYonz]

Instead of InboxScreen -- onPress/ Stack.Screen/IonIcons , I wanted to see my react-native JSX stack + JS code

<Stack.screen
  <View
    {editMode &&
      <Pressable
        onPress
...
Being able to do either JSX or JS only makes it unusable for either in a JSX world the examples are showing code folding in both cases and the middle is the full code

[zardoy]

can we open a separate issue for this? it's just a mess to read..