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

Using a shared .stylelintrc.json not in current working directory in user settings of vscode #82

Closed
yipei1028 opened this issue Mar 17, 2020 · 9 comments
Labels
type: enhancement a new feature that isn't related to rules

Comments

@yipei1028
Copy link

yipei1028 commented Mar 17, 2020

What is the problem you're trying to solve?

Say I put the .stylelintrc.json in a shareable-config file (all the dependency and required node_modules are there, and this configuration is not in my current working directory) so I can let all my projects use the same version of stylelint and related dependency.

Is there any chance to use something like ‘a string of path’ to replace the vscode settings.json stylelint.config replace by a .stylelintrc.json file which is not in current working directory

What solution would you like to see?

(in vscode user settings.json)

{ "stylelint.config”: “../code/my-sharable-stylelint/.stylelintrc.json” }

@tkforce
Copy link

tkforce commented Mar 18, 2020

Would love to have this feature as well ;P

@skyjan0428
Copy link

It would be more handy to have this feature!

@ychi
Copy link

ychi commented Mar 18, 2020

A user-level configuration would be convenient.

@jwu7778
Copy link

jwu7778 commented Mar 19, 2020

For now, we have the property “"stylelint.stylelintPath" to use the stylelint from other directory like the shareable configuration, is it possible to have the similar functionality so that only one configuration will be needed? Or just I miss anything. Thanks anyway.

@ntwb
Copy link
Member

ntwb commented Mar 20, 2020

I think this alternative might work, setup a workspace with the root folder the directory with your stylelint config in that folder, then add your other projects as sub-folders, e.g

  • Project root: ~/code
  • stylelint config: ~/code/.stylelintrc.json
  • Project One: ~/code/project-one
  • Project Two: ~/code/project-two

@yipei1028
Copy link
Author

yipei1028 commented Mar 20, 2020

Hi @ntwb,
Not sure if we are on the same page...Are you suggesting that
add the following line in VSCode settings.json?
"stylelint.config": "~/code/stylelintrc.json"

For now, I will get the error message (please see the attachment). Correct me if I take it in a wrong way.

Screen Shot 2020-03-20 at 3 55 37 PM

Looking forward to your reply!

@ntwb
Copy link
Member

ntwb commented Mar 20, 2020

Here's a quick test:

The files and file tree:

.
├── project-one
│  └── project-one.css
├── project-two
│  └── project-two.css
└── stylelint.config.js

The root folder has the stylelint config file, in each of the project directories I ran git init and committed the CSS file

image

You could also do the same sort of configuration using VS Code Workspaces for something even more advanced

@Aragur
Copy link

Aragur commented Sep 26, 2020

So I'm facing sort of the same issue.
I have a server directory where all my serverside code lifes. There's my .stylelintrc.json, my package.json and all installed NPM Packages.
I also have a webapp direcotry where all my webapp related files are sitting.
Now my questeion, how can I get this plugin to work in my webapp direcotry with installed NPM packages from the server directory?

My File-Tree:

.
├── server
│  └── .stylelintrc.json
│  └── ...
├── webapp/src/scss
│  └── style.scss

@adalinesimonian
Copy link
Member

I think there are better ways to do this sort of thing that don't add more complexity to the extension. One example is the fairly common practice of creating a package with the configurations you want to share and then either linking it to the projects that need to use it or if you work on a team, publishing it as a package and having it as a dependency in your projects. In any case, I think this isn't something we'd want to do in-extension. Thanks for your understanding!

@adalinesimonian adalinesimonian added type: enhancement a new feature that isn't related to rules Won't Fix labels Oct 28, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: enhancement a new feature that isn't related to rules
Projects
None yet
Development

No branches or pull requests

8 participants