Closed Angelk90 closed 1 month ago
@jasonplatts, I think that it's related to #76
@pkasila : I don't know, do you think such a thing could be useful? Do you see it more as a plugin?
My take on this is that we should enable it in our plugin API so plugin developers can choose what action they want to perform on "play". Similar to how VSCode handles it.
As @lukepistrol said, we implement API for extensions to provide targets, tests and so on. So, NodeJS extension reads package.json
and creates npm start
target and anything else using Extension API and these targets appear in the UI
Yeah, I agree. It seems like it might be better as an extension. Nova offers tasks, https://docs.nova.app/extensions/run-configurations/.
As @lukepistrol said, we implement API for extensions to provide targets, tests and so on. So, NodeJS extension reads
package.json
and createsnpm start
target and anything else using Extension API and these targets appear in the UI
Here is the link to VS Code tasks. https://code.visualstudio.com/docs/editor/tasks
The Task Provider should allow extension developers to define external tools that can be run from a CodeEdit menu option and the command palette. These tasks should be capable of running command line tools, such as Grunt, npm, Rake, Gulp, etc. Results from running these tasks should appear in the console within CodeEdit.
https://code.visualstudio.com/docs/editor/tasks https://code.visualstudio.com/api/extension-guides/task-provider
Are we going to do something like Nova, where you have to create a custom task for each project? When trying out Nova, I found it annoying to have to create a custom task for each project I go into.
In VS Code, npm scripts have a separate window.
And for other files like Python and vanilla JS, I use vscode-code-runner so I can just press the play button in the corner to start debugging.
Are we going to do something like Nova, where you have to create a custom task for each project? When trying out Nova, I found it annoying to have to create a custom task for each project I go into.
I think that's annoying too. I really like how it works in TextMate. There's a convention that a bundle provides a Run and/or Build command. They all are named the same and all use the same keyboard shortcuts. For something like Ruby it will just run the current file. For RSpec there are a couple of commands. The regular Run command runs all tests in the current file. Then there are commands for running a single test within a file and to run all tests in the selected directory. I'm using this feature very frequently. I just need to verify a couple lins of code, I open a new document type the code and run it, I don't even need to save the document for it to work. Super convenient.
For the D programming language I made the default Run command a bit smart. If there's a standalone file open, it will just compile and run the resulting executable. If there's a project directory open, it will look for the for a run.sh
file in the directory and execute that if present. Otherwise it will look for a build configuration file, run the build tool and then the resulting executable. Finally, if none of those files are present it will behave as a standalone file is open. In addition to that there's a Run Single File command that will always only compile and run the current file, regardless if a directory is open or if it's a standalone file.
This would be create if it could be supported. Either by convention or by an API. Also, I wouldn't mind if it was possible to support project specific configurations. For the D Run command, I'm using the run.sh
approach as a workaround for the lack of project specific configurations in TextMate. This allows to pass arguments to the executable.
I'm taking my hand at this and on discord there is general agreement that there should be some kind of configuration that users can access on how the project is run, how should this be implemented?
@iggy890 I don’t want to step on your toes with this but based on your latest commits in PRs I think this is better suited for a more experienced developer since this will be an important part of the app and most possibly it needs to align with our yet-to-come extensions API.
@iggy890 I don’t want to step on your toes with this but based on your latest commits in PRs I think this is better suited for a more experienced developer since this will be an important part of the app and most possibly it needs to align with our yet-to-come extensions API.
That makes sense my basic implementation is here (someone could continue it here just create a PR or DM me on discord and I'll add you as a contributor to that branch): https://github.com/iggy890/CodeEdit/tree/run-code
@lukepistrol : I'd give @iggy890 a chance, creating an initial base wouldn't be bad.
Small suggestion adding to my prev comment: https://github.com/CodeEditApp/CodeEdit/issues/262#issuecomment-1402448294:
like IntelliJ, the standard option is just to run the current file. but if you want to have some custom configuration, you can create a new configuration file for that workspace with the dropdown. but it defaults to just running the current file
Codeedit would need to have some custom task.json file that would read the custom config.
Don't know how npm scripts would work, identify npm start
as standard?
Is your feature request related to a problem? Please describe.
https://user-images.githubusercontent.com/20476002/160231556-fc2c16ef-3978-45f9-9097-9602c20313a1.mov
You know that XCode has a menu like this, which allows you to run tests and other things as well as run the program.
It would be useful to have something like this, but which allows you to run scripts found in the
package.json
file.Script package.json example:
Describe the solution you'd like So if the project contains a
package.json
file it tries to read it, if it finds any scripts, it puts them in the menu to let you run them. When one of the scripts is pressed, it starts the script in a new shell.