It feels a bit strange to move the big project tasks (theme watching, changelog, cherrypick) to this toolkit package that I thought would be more focused on building & testing plugins.

But maybe mixing these is fine?

@ryantxu @torkelo see 4caadbf for first attempt for having shared tsconfig for plugins. I assume that there will be cases when extending tsconfig will be necessary.

According to microsoft/TypeScript#29172 some paths are resolved relatively to tsconfig.json location. For example, if I extend the base config from grafana/toolkit (btw got it working only with such extend: "extends": "./node_modules/@grafana/toolkit/src/config/tsconfig.plugin.json"), then in Ryan's grafana-live-app the absolute imports does not work until I override baseUrl in local tsconfig.json . This sucks a little bit unfortunately, seems like the plugin will have to have tsconfig.json specified anyways.

Another issue is that in order for the IDE to pickup grafana/toolkit tsconfig we need to extend it in the local tsconfig. Couldn't make it work with "extends": "@grafana/toolkit" only, as rollup fails when extendig that config.

FYI for testing purposes use yarn link in grafana toolkit root dir.

@torkelo @ryantxu see https://github.com/grafana/rss-panel/pull/1 for grafana-toolkit usage reference. Especially interesting is tsconfig.json. Apparently, all path specific options need to be defined in that file for tsc to pickup correct directories (otherwise paths are resolved relatively to original tsconfig file).

I don't like how the default config is extended though, as it requires either path to node modules (as in the example PR https://github.com/grafana/rss-panel/pull/1/files#diff-e5e546dd2eb0351f813d63d1b39dbc48), or we could also introduce package with default tsconfig for plugin. I don't like this idea though.

But to be honest I think that with any of the approaches we take there will be possibility to override defaults, so maybe we should basically provide a basic tsconfig.json file when we will introduce some plugin boilerplate?

I think we should merge this soon even if the plugin build stuff still needs work.

@dprokop -- I'm trying to make this work with old plugins like:
https://github.com/grafana/kubernetes-app/tree/using-toolkit

I added the option to use the local tslint.json if it exists, this way plugins could migrate slowly if necessary.

I also added the fix=true flag. We could have a second task, but with git I think autofix is the better behavior

@ryantxu I have created #17819 to keep track of the progress/todos