Open davidchin opened 6 years ago
We use the prepare step to download the config from GitHub and overwrite the one in the repo. If you have local overrides in your config you'll have to use multiple config files and have one require the other.
@davidchin Were you able to get it working somehow?
@wingrunr21 Could you pls give some code sample of how you're getting around this problem?
Well, it's basically what I said above. We do this for our shared TSLint config
...
prepare:
fetch:
- url: 'https://raw.githubusercontent.com/GuildEducationInc/tslint-config-guild/v1.0.0/tslint.json'
path: 'tslint.json'
...
@wingrunr21 I believe this is to share the same config among multiple projects, right?
However, I'm still failing to see how this could solve the problem of the dependencies not being available in the environment -- as noted in the original question.
That’s not the original question. The very last sentence asks how to extend a shared config.
I believe the root problem of this issue isn't related to what you're saying, unfortunately.
Here's the thing, when you try to extend some custom tslint
config that comes from another npm
package, it won't be available in the [codeclimate] environment where the analysis runs.
With that said, and back to your config again, it seems you made use of 2x tslint
configs that comes from npm
packages.
I wonder if those are available in the [codeclimate] environment when you push new code.
Take it or leave it. We use this across many projects for both TSLint and ESLint configs and it properly brings our shared configs into our repos for CodeClimate analysis. I know it works. The only aspect that doesn't work is when our shared configs depend on upstream configs that aren't in the engine (eg tslint-no-circular-imports
). The ESLint engine just fails to load those rule sets and fails the rule. The TSLint engine is a bit less robust.
You may want to go read the prepare
docs. We aren't using 2x configs as the config in our repos is under the file tslint.json
. The prepare step replaces that config with the one downloaded from GitHub. This basically "inlines" the shared config prior to the analysis. If your shared config is just a bunch of rule sets (as is the case with the @bigcommerce/tslint-config
config) and doesn't depend on upstream shared configs, then this method will work seamlessly and is thus why I posted it here.
The only aspect that doesn't work looks to me like the only problem.
But I got your points and how you override your config file.
Thank you for the insights.
I have a shared TSLint config that I use in multiple projects. i.e.:
However, this doesn't work because
@bigcommerce/tslint-config
is not available in the environment. Do you have any idea on how to extend custom TSLint config?