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

File templates - additional features #42

Open
chuckhendo opened this issue Nov 22, 2017 · 4 comments
Open

File templates - additional features #42

chuckhendo opened this issue Nov 22, 2017 · 4 comments

Comments

@chuckhendo
Copy link
Contributor

I see that file templates were recently added, although there really isn't much documentation on them. I wanted to see if you had any additional plans on what direction you want to take file templates, particularly in regards to the list below. I would be happy to do any/all of the work for this, but I don't want it to interfere with your plans. Some of it might also belong in a completely separate extension.

  • Templates stored in the project rather than globally: Right now, the template path is determined by resolving based on the rootDirectory. It would be nice if we could do something like ".js": "./templates/Component.js" to tell it to look for the files in the project folder. This makes sense as my JS templates may change from project to project, and these would also be able to be shared with other users of the project
  • Template variable replacement: Several templating extensions exist, and most of them have some ability to replace variables in the template. https://github.com/brpaz/vscode-file-templates-ext even lets you put arbitrary variables in your template which it will then prompt the user for
  • Automatic folder placement: If we can get this extension working better with workspace settings, being able to change the "relativeTo" path based on the type of file would be very powerful. Perhaps I have a project where I should place all .js files inside of a scripts folder. Or CSS inside a styles folder. This can all be configured via the workspace settings
  • Multiple types of templates per extension: This is the one that might need to fall outside of what vscode-new-file does. If I'm working on a React project, for example, I might have multiple types of components. PureComponents, functional components, containers, etc. However, these all have the same extension. Perhaps we prompt the user if there are multiple templates for the same extension. We would have to adjust the config, perhaps to something like this:
"newFile.fileTemplates": [
   {
      "extension": "js",
      "name": "React Component",
      "path" : "./templates/component.js",
      "targetPath": "./js/components" // if we implement bullet 3
   },
   {
      "extension": "js",
      "name": "React Container",
      "path" : "./templates/container.js",
      "targetPath": "./js/containers" 
   }
]

Very curious to hear your thoughts here, @dkundel. I've thought about building a extension to do this style of templating for a while, but I really like this extension, and would rather contribute if it makes sense.

@dkundel
Copy link
Owner

dkundel commented Nov 23, 2017

Hi @chuckhendo,

Thanks for your great suggestions. I added templates at one point but haven't had the time to write documentation or really configure them for my own use case.

I think the first two suggestions are stuff we can totally add out of the box. We could do the variable replacement part in a naive way first where we basically provide:

  • file name
  • variations of the file name like kebab-case, snake_case, camelCase, CamelCase based on functions like the ones in lodash
  • file path

If people like it and want more configuration we could explore if there would be a nice way to interop with the extension you linked using commands.executeCommand.

I get your idea with the third bullet point but I'm wondering how we would build this in an easy to configure way without having to add too much redundant code. It seems to work well with your example above but the question would be how it would interact with the other configuration options.

As for the fourth one, I think that's something that we could add without adding too much configuration complexity. Especially if we do it in the way that the selector box only shows up if there are multiple templates for the same extension.

Right now this should be possible if you would name your files like foo.container.js or foo.component.js because then you could use the respective extensions.

I think we should start with the first two features and improve the documentation on the templating feature. Once we have that going we could dive into the other ones. What do you think?

Cheers,
Dominik

@chuckhendo
Copy link
Contributor Author

Great idea! I'll be able to take a look at that in a few weeks

@Telokis
Copy link
Collaborator

Telokis commented May 13, 2018

@chuckhendo Any feedback on this?

@chuckhendo
Copy link
Contributor Author

@Telokis I keep wanting to take a look at it, but I just haven't had the time recently. Hope I can real soon

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

No branches or pull requests

3 participants