Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider folding support for Dockerfiles #230

Open
rcjsuen opened this issue Mar 7, 2018 · 3 comments
Open

Consider folding support for Dockerfiles #230

rcjsuen opened this issue Mar 7, 2018 · 3 comments

Comments

@rcjsuen
Copy link
Contributor

rcjsuen commented Mar 7, 2018

The VS Code 1.21 release added a new (proposed) API for folding support. The API currently includes three different "types" of folding.

export enum FoldingRangeType {
	/**
	 * Folding range for a comment
	 */
	Comment = 'comment',
	/**
	 * Folding range for a imports or includes
	 */
	Imports = 'imports',
	/**
	 * Folding range for a region (e.g. `#region`)
	 */
	Region = 'region'
}

Should folding support be added for Dockerfiles? If yes, what should be considered as something that can be folded by the user? And what "type" should they be? I think the obvious one is multiline comments but what else?

Here are some scenarios I thought of:

  1. any instruction that spans multiple lines (Region type)
  2. only RUN instructions that span multiple lines (Region type)
  3. build stages, if you have two or more FROM instructions then every FROM that gets detected would be considered a folding region for its build stage (Region type)
  4. initial set of (ARG) instructions that come before the first FROM instruction in a Dockerfile (could be Imports or Region type, I'm not sure)

If we consider both 1 and 3 then there is a problem because you end up returning two different folding regions with the same starting line. Consider the following Dockerfile:

FROM node
  AS setup
RUN /blah/blah
FROM node AS test
RUN /blah/blah

This Dockerfile would have a folding region from 1-2 (for the multiline FROM instruction) as well as 1-3 (for the setup build stage). I'm not sure how VS Code handles this right now but it doesn't feel like a great user experience. I do realize that this example is a bit contrived as I don't think anyone writes FROM instructions like that but I think it's something that needs to be considered in the implementation.

Looking forward to any feedback and comments from the vscode-docker community! Thanks!

@rcjsuen
Copy link
Contributor Author

rcjsuen commented Sep 7, 2018

Folding support for comments was added with #392.

I've thought about this some more and am considering adding folding support for build stages, multi-line instructions, and such without specifying a type (as they really shouldn't be considered in the same vein as a C# #Region block).

I'm open to feedback but that is my current plan.

@clecap
Copy link

clecap commented Nov 6, 2022

Looks like the user-defined code folding with a #region comment is not yet supported.

It would be great if this could also be added.

@juarezr
Copy link

juarezr commented Dec 11, 2023

One thing I'm quite missing when editing Dockerfiles in VS Code is `region folding.

Besides code organization, region folding is useful when creating Dockerfiles for many tasks like:

  • Focusing on one section/piece of code, hiding others to avoid distractions.
  • Folding sections with many lines for comparing the code above and below these sections.
  • Formalizing and giving a title for a section of code, categorizing it according to its purposes. E.g.: region apt, region python, region network, etc...

Regarding the feedback that @rcjsuen talks above, perhaps it's worth considering that:

  • Structural folding, using language features such as build stages, and multi-line commands, is great and brings quickly valuable agility without requiring any effort from the developer.
  • Region folding also contributes a lot and can perfectly complement and coexist with structural folding because:
    • It will not obstruct or clutter the code because it's opt/in.
    • There will be no effort or tax for the user who does want to use them.
    • It allows the developer to put it only when and where he wants.
    • Being comments, it does not interfere with the code itself.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants