Various tooling improvements from other plugins

[lieut-data]

Summary

Upstream various changes from other plugins:

• collapse golangci-lint into just the existing check-style target
• support DEBUG=1 server target
• eliminate (debug|deploy)-dist to DEBUG=1 (dist|deploy) for simplicity
• introduce attach and attach-headlesss for easy dlv setup
• test shouldn't change files via npm run fix
• introduce reset to disable/enable plugin
• introduce kill to forcibly kill all instances of a plugin
• rename build/deploy to build/pluginctl, now with reset functionality
• eliminate copy-to-install behaviour from build/pluginctl
• enable --cache when running eslint
• .npmrc specifies save-exact=true
• introduce watch to build, deploy and update webapp changes automatically
• touch node_modules instead of .npminstall
• support devtoolNamespace

Fixes: https://mattermost.atlassian.net/browse/MM-11867

[lieut-data]

Skipping 3: QA Review, since only tooling changes.

[lieut-data]

@cpoile, my hope is to downstream this back to incident response, with just one additional change in build/custom.mk, otherwise having Makefile be 100% a match for the starter-template.

I took the opportunity to slim out some of the code in incident-response around copying plugins instead of Client4-installing them, since GOPATH is long dead, and the mmctl strategy is fast becoming the popular approach. I also took some opinionated strategies with target naming, also removing the background nature of attach-headless and forcing you to Ctrl-C it instead.

[hanzei]

@lieut-data is there any urgency with reviewing this PR? I would love to understand the details before giving a review, but this will take time.

[lieut-data]

@hanzei, there's no immediate hurry -- I can propose the same changes into incident response in parallel, and if we diverge, even up later.

[mickmister]

I apparently missed this PR and have a similar effort at https://github.com/mattermost/mattermost-plugin-starter-template/pull/99 . I got most of the inspiration from the Incident Response plugin as it has a pretty robust dev setup. Two additions I've made:

• make webapp-debug-deploy: Compile webpack with dev config settings and deploy the plugin, but do not use watch mode, as opposed to webapp-debug which does use watch mode.
• Add devtoolNamespace to the webpack config to allow the plugin to have its own namespace in the dev tools source tab. Docs can be found here. Here's an example with the Jira and GitHub plugins:

I mainly made the PR to get some eyes on it before holistically applying the additions to the other plugin repos. It would be immensely helpful to get all of the plugins up to speed on these configurations!

I know there is a task to have various aspects of the repos automatically synchronized, but I think this first go-through should be done manually as there are some intricacies to make sure it is all configured correctly.

[mickmister]

Another good thing to add would be an .npmrc file at the root of the webapp folder, that enforces dependencies to be installed with save-exact.

[lieut-data]

@mickmister, I've gone ahead and made the following changes:

• Added the requisite .npmrc
• In lieu of make webapp-debug-deploy, I've just made DEBUG=1 deploy, with make watch (or DEBUG=1 make watch) for the specialized watching behaviour. Note that I moved away from the -debug variants since there were so many desired permutations, and it seemed easier to just export DEBUG=1 into my environment and get this "for free".
• Added devtoolNamespace as per your excellent recommendation

Can you and @cpoile give this a whirl and see if it fits your workflows / make intuitive sense?

[mickmister]

@lieut-data I'm not sure I see much benefit from using make watch without DEBUG=1, so it seems off to me to have non-debug to be the default. I don't see why I would want the watch behavior, without the benefits of the debug build, but I suppose I understand if it is desirable to be able to replicate the production build in rapid development.

Regardless of that point, I do like the explicit mention of watch in the command.

[lieut-data]

I suppose I understand if it is desirable to be able to replicate the production build in rapid development

Yeah, this was exactly my imagined use case. I've often had to debug issues that didn't manifest in debug builds, but could be reproduce in production builds. By exporting DEBUG=1 to your environment, you could get the desired default in most cases. Actually, this reminds me that I haven't updated the README.md to document all this -- will do before merging.

[mickmister]

I think a make disable command would be great to include here. It would do the same thing make reset does, but without the final enable. I've just had the need for one and it seems natural to use.

[mickmister]

I'd also like to mention an open PR https://github.com/mattermost/mattermost-plugin-starter-template/pull/86 that is meant to synchronize changes like the ones in this tooling improvements PR. I'd like to make sure we synchronize on upgrading all things that the PR supports, after this one is merged. The PR is stale, but I've pinged the contributor to see how he's doing.

[lieut-data]

Thanks, @mickmister! I've updated with your excellent suggestions.