Skip to content

Add Visual Studio Code Dev Tools #15

@TomStrepsil

Description

@TomStrepsil

Issue

Varying code, or accepting a variant as a new baseline, is not as seamless an experience as it could ideally be.

There is no helpful linting to indicate where rules of the toggle convention are not being adhered to (e.g. folder structure is wrong, __toggleConfig.json is pointing to non-existent modules, etc)

Details

A IDE extension could automate:

  • varying code modules
    • for consumers that want to preserve a commit history (i.e. don't use "squash merge" as we mandate from feature branches) could look to scripts such as gitCopy that will keep a common history between control and variant
    • utilise git-merge-file when "concluding" / "accepting" a variation as the new base / control?
    • automate deletion of all folders matching a filename convention, when a feature is junked?
    • although VS code is good at updating import paths when moving to nested hierarchies, it must be done "in the right order" for it to work - i.e. a dependency chain where multiple files are being varied needs to be done in an appropriate order.
      • It does not automatically recognise and update paths in jest mock statements, so specialised tooling could keep these in line (see vs code issue)
  • generation of union types, for TypeScript consumers
    • when variations change the type signature of a module, options to extend/modify the base type could be supported.

It could add some convenience methods:

  • given point cut configuration(s), it could list potential filesystem matches noticed by the defined variantGlobs, and potentially via a "dry run" of the compilation, list actual matches connected to the entry point(s).

It could add some linting rules:

  • control code should not reference variant code directly
  • variants should probably not cross reference each other
    • but may want to in some circumstances, so could be a warning

It could recognise when toggle point exists, but no matching variant files exist (perhaps on each file modification noticed?)

To support any and all filesystem convention, the "rule set" for the automation would probably need to be defined and live with the "convention" (see #13)

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions