Skip to content
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 support for json config files #899

Open
wants to merge 9 commits into
base: main
Choose a base branch
from

Conversation

xt0rted
Copy link
Member

@xt0rted xt0rted commented Apr 20, 2020

Pull Request Badge

Checklist:

  • If this PR is a new feature, please provide at least one example link
  • Make sure all of the significant new logic is covered by tests

This is a quick attempt at adding support for the json config format used by linting tools (they usually support js, json, and yaml but this is just for json right now). @fregante this was your request, do you know of any other json config files we could add to the list? I was looking at eslint but their format doesn't really work with this.

Closes #552


babel

stylelint

tslint

function linkDependency(blob, key, value) {
let regex;

if (Number.isNaN(key)) {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When the value is an array the key values are numeric so jsonRegExValue doesn't work.

@fregante
Copy link
Collaborator

fregante commented Apr 20, 2020

In addition to the ones you already added (👌) there’s also ESLint and any tools that also support adding their config to package.json, on keys like you can see here: *.extends, *.plugins, *.rules (maybe a bit too much), ava.require

@stefanbuck
Copy link
Member

As @fregante already mentioned, ESLint might be interesting to cover as well, although from my experience many projects are using the .eslintrc.js file over .eslintrc.json. Would be good to know the market share of json vs js config files.

Btw. I maintain a module called eslint-rule-docs which was intended to become part of OctoLinker as well at some point, but I fall into the trap of trying to cover all possible eslint config files.

@xt0rted
Copy link
Member Author

xt0rted commented Apr 20, 2020

Just pushed some more changes that adds package.json support for ava, babel, eslint, stylelint, and xo.

The issue with eslint is it seems like most of their references don't use the full package name so we're not able to link them. This probably needs its own plugin so we can handle looking those things up differently.

@fregante
Copy link
Collaborator

This is looking great!

'$.stylelintConfig.extends': linkDependency,
'$.xo.extends': linkDependency,
'$.xo.parser': linkDependency,
});
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if it makes a difference performance wise to have dedicated plugins for each config, but most likely it's just micro optimisation. I'll look into it to get a better understanding if this is worth changing or not.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I checked a few different config files and this code run on average in less than 5ms 😄

@stefanbuck
Copy link
Member

Looks amazing @xt0rted. I don't think we need to add E2E tests for all of them but maybe for the most common once like for babel, eslint and config within a package.json file

@xt0rted
Copy link
Member Author

xt0rted commented May 28, 2020

@stefanbuck I was adding tests in for this and trying to get the rest of the areas implemented but noticed an issue in how the links are being handled. If the matched text exists more than once in the file, such as @babel/plugin-proposal-class-properties, it's resulting in nested links like this:

image

This is the file I was testing against https://github.com/jassi1124/reaction-testing/blob/843f14aec572c3de4551b8e180698495ccd19458/package.json

I'm not really sure what I can do to prevent this.

@stefanbuck
Copy link
Member

Looks like a bug, which even exists for single dependencies. In the old implementation of insert-link.js there was a check to prevent such a behaviour, but now that we process line by line I thought this isn't needed anymore. It also exists in the current master so worth fixing it separately. I'll look into it
image

@stefanbuck
Copy link
Member

🤦 I had two versions of OctoLinker running (local and the live version from the store) and therefor OctoLinker run twice. However, I'll look how we can fix it here

@stefanbuck
Copy link
Member

Was the screenshot taken from your regular chrome instance or during E2E tests? I'm asking because it seems to work for me

@xt0rted
Copy link
Member Author

xt0rted commented Jun 2, 2020

It was with my local dev instance from yarn chrome-launch and it was the only extension running.

@stefanbuck
Copy link
Member

Mhhh is it still behaving like that? I run yarn && yarn chrome-launch on this branch and it doesn't wrap the links many times.

@xt0rted
Copy link
Member Author

xt0rted commented Jun 2, 2020

I have changes that weren't pushed up yet because I'm still playing with it. Give this branch a try. It's still a work in progress but that's the code that was triggering the issue for me.

@stefanbuck
Copy link
Member

Strange, it's still behaving as expected.

image

@stefanbuck
Copy link
Member

Sorry it was my fault. I assumed yarn chrome-launch does a build as well, which isn't the case. I use yarn start and load the extension as unpacked extensions via chrome://extensions/

@stefanbuck
Copy link
Member

but now it's too late for me 😉 I'll continue the hunt tomorrow

@xt0rted
Copy link
Member Author

xt0rted commented Jun 2, 2020

I've been using a split terminal in vscode, one has yarn start and the other yarn chrome-launch.

@stefanbuck
Copy link
Member

I pushed a fix onto this branch c6dd225 which is fixing the issue by checking whether or not the node or parent is already wrapped. I need to think about how to test this best.

@xt0rted xt0rted changed the base branch from master to main September 21, 2020 21:49
@stefanbuck stefanbuck marked this pull request as ready for review September 24, 2020 20:42
@stefanbuck
Copy link
Member

I pushed a test case to ensure links are not wrapped twice. This covers c6dd225

Copy link
Member

@stefanbuck stefanbuck left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Amazing feature @xt0rted

@stefanbuck
Copy link
Member

@xt0rted is unable to work on this PR in the near future. I'll have a closer look once Safari support #29 is added.

@fregante
Copy link
Collaborator

I'll have a closer look once Safari support #29 is added.

How is that related?

@xt0rted
Copy link
Member Author

xt0rted commented Jan 16, 2021

I'll finish this up next week

@stefanbuck
Copy link
Member

How is that related?

By the availability of my time 😉 I have to juggle kids, my day job and way too many side projects which is quite difficult during these crazy times.

@fregante
Copy link
Collaborator

fregante commented Sep 1, 2021

I hope to see this merged eventually ☺️

@Yash-Singh1
Copy link

There is also markdownlint and cypress.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

Add support for tsconfig's extend
4 participants