Roadmap

[tscpp]

Stage 1

• [x] Move every kolint related utility into one workspace
  • [x] knockout-ssr
  • [x] vscode extension
• [x] Implement language server
• [x] Resolve tsconfig from the current file in LSP
• [x] Bugs
  • [x] kolint/kolint#323
  • [x] kolint/kolint#333
  • [x] kolint/kolint#340
  • [x] kolint/kolint#337
• [x] Workspace
  • [x] #2
  • [x] Configure eslint
  • [x] Configure changesets
  • [x] Setup tsconfig paths

Stage 2

• [x] #5
  • [x] Fix version commit to include pre.json
  • [x] Don't auto-commit changesets
• [ ] #44
  • [x] #18
  • [x] Switch to new parser
  • [x] kolint/kolint#336
  • [x] kolint/kolint#285
  • [ ] kolint/kolint#272
• [x] Add some coverage
  • [x] #20
• [x] Bugs
  • [x] #8
  • [x] #10
  • [x] #9
  • [x] #17
  • [x] #23
  • [x] #24
  • [x] #31
• [x] Add documentation (https://kolint.github.io/next)
  • [x] #7
  • [x] Import docs from knockout-lint
• [x] #34

Stage 3

• [ ] Move code to kolint/kolint
  • [ ] Fix repo field in package to point to kolint/kolint
• [ ] Quality updates
  • [ ] kolint/kolint#341
  • [ ] kolint/kolint#339
  • [ ] kolint/kolint#335
  • [x] #29
• [x] Optimize CI

Stage 4

• [ ] Allow for only linting (without type-checking)
• [ ] Document release workflow in contributing guide
• [ ] Automatically create github releases for the linked packages' version

...

[tscpp]

cc @ondrejmirtes

[tscpp]

Stage 1 completed 🥳

[ondrejmirtes]

How can I test this please?

[tscpp]

How can I test this please?

I haven't completely figured this out yet. You can test the functionally from within the repo, but I need to document how to test the packages outside of the repo.

I am working on a contributing guide (not merged yet): https://github.com/kolint/next/blob/3e56000/contributing.md

@ondrejmirtes

[ondrejmirtes]

Can you publish the final form (a kolint CLI command basically as it's known today) so I can test it and give feedback? It'd be useful before the other stages.

[tscpp]

Can you publish the final form (a kolint CLI command basically as it's known today) so I can test it and give feedback? It'd be useful before the other stages.

Sure. I'll pre-release a major.

@ondrejmirtes

[ondrejmirtes]

@tscpp A tip: It's worth it to automate the process as much as possible in GitHub Actions, so that releasing a new version is basically done by pushing a new Git tag, or manually running a workflow (workflow_dispatch).

You could release versions such as 0.0.1, 0.0.2 etc. so that it's easy to test these changes easily, and give feedback. Thanks!

[tscpp]

@tscpp A tip: It's worth it to automate the process as much as possible in GitHub Actions, so that releasing a new version is basically done by pushing a new Git tag, or manually running a workflow (workflow_dispatch).

You could release versions such as 0.0.1, 0.0.2 etc. so that it's easy to test these changes easily, and give feedback. Thanks!

@ondrejmirtes

I have some experience managing monorepos, and I basically fear using automated releases. They always manages to break. Plus, some packages are versioned independently (e.g. eslint-plugin) so tagging won't work.

It's possible I'll configure this in the future, but from my experience, it always manages to steal way too much time. Thanks for the tip though! 🙂

For now, I think Nx works great for this. So it's no harder than running nx release from the command line.

I'm working on getting the release to work right now

[tscpp]

All kolint packages are published under the @kolint/ scope now. @kolint/check is the package containing the CLI for checking files. I will maybe rename the package to @kolint/lint or @kolint/linter later.

I have not fully tested all packages yet, but I have at least made sure it runs. Stuff may be broken after the refactoring. I am writing tests, but not everything is covered yet.

npm i -D @kolint/check@beta
npx kolint view.html

cc @ondrejmirtes

[ondrejmirtes]

Thanks! I'm going to be opening issues with the problems I find.