Using Ember-cli in Visual Studio #3746
Comments
|
You're working against the grain here and it's going to burn imo Sent from my iPhone
|
|
You could certainly use visual studio as your editor, but are you wanting to find a way to avoid using the command line in any way? |
|
@edson- I have used VS for my REST api and web server, while ember-cli and (insert js editor here) for my ember client. Then I use scripts to copy my /dist folder to a folder under my web server so it can serve it up. Hopefully this can give you some ideas of how the two can co-exist. |
|
VS already has 1.0 tools for node.js and AFAIK Angular support. Ember CLI should be integrated in future with VS. Maybe some community suggestion to VS team should be created somewhere? |
|
I'd follow @kellyselden's advice and use VS for the API and Sublime/Vim/Atom/whatever for ember. I'm in the same boat (C# API, ember client) and that's what I'm doing and I don't have any real issues (other than general ember-cli on Windows slowness). I have a config environment setup so that I can run my client against the local debug instance of my API using FWIW rumor mill has it that MS is working on first-class support for ember-cli in VS 2015. |
|
I've been tackling this pony for the last few hours and had some success with custom build events inside a heavily modified .csproj file but it does really seem like a square peg in a round hole. I tried taking a nodejs project from here (https://nodejstools.codeplex.com/) and modifying it but it appears that one or more of the node_modules/ember modules have file names that are too long and cause Visual Studio to crash. Also it appears ES6 intellisense is not there yet for plain old JS files. One can only hope that VS2015 has better support. That or the community needs to create some custom project templates or build tools. |
|
I would love ember + resharper!! |
|
@Twinkletoes Atom has javascript autocomplete (intellisense) I think. Anyways, since this is not a bug in ember-cli, I'm going to close this issue. You may want to continue the discussion at discuss.emberjs.com or stackoverflow. |
|
So we have been exploring deeper visual studio integration. cc @felixrieseberg We can use this as a tracking issue |
|
I've ditched visual studio in favor of atom and its lead me to look into other back end tech such as Go and Node I'm loving the lightweightness of it all and couldn't care less about my loss of Resharper Put it this way. Builds are sub 1 second with my node and ember setup C# can be anything from 1 minute to 15 minutes depending on what level of hell I've been assigned to. NOT having all that intellisense and refactoring bloat has made me think about the design of my code more up front, before I put hand to keyboard. It's lightweight, fast and you never find yourself sat there gormlessly staring at your monitor while visual studio is busy doing something you certainly didn't ask it to do and you're contemplating what the next level of hell feels like because this ones pretty ripe. My ide spins up in about 1 second and doesn't have any bullshit sln or csproj files and my source control certainly IS NOT hard linked to my build definition, bug tracker or anything else that desperately screams "we're integrated, you can't split us, you have to pay for all or nothing" - for those happily unaware, I'm talking about TFS - the single major cause of aneurisms, mad cow disease, high blood pressure and rainy days throughout this planet*. Now do not get me wrong, I don't see the 12 years I spent with c# as any kind of waste. But I am wiser now to what is essentially gimic, bloat, over complexity and I really do know when I'm being fenced in. Script# looked interesting but I'm not sure it has the velocity it needs to make c# truly lightweight. I tried keeping our backend stack c# until I was blue in the face. Tried running it under mono: create Vagrant box, compile Mono inside it, compile MonoDevelop inside it, install all the other deps and it was buggy as f*^%k, slow, complicated and an all round headache. Anyway, my point being that you'd be better off just going with it. If you find keeping the back end and front end dev experience so different a ball ache I'd ask yourself "what does c# give me that is worth working against the grain" because I promise ember gives you a whole lot and c# is replaceable and you'd not regret swapping out c#. Not one bit. W:// *slightly exaggerated but if MS were responsible citizens they would take it out back and hit it over the head with a baseball bat - they'd also actually make an MS version of Linux. Why not?! It'd be a great idea And we'd all love them for it. The msdos phone should stay an April 1st thing though. Sent from my iPhone
|
|
If you're doing this you'll need to get ember on NuGet, big enterprise (like the one I 9-5 for) wouldn't even consider pulling in deps over NPM, they kind of understand NuGet but NPM would be a step too far. Maybe a vsix like SpecFlow provides? Thing is VS has it's own templating engine for code generation (T4) so there will likely be a lot of duplication and working outside of the norm. Which means lots of moving parts. Meh If MS can get behind you on this you'd be in with a good chance but I don't see how VS will be able to keep up with the way things are going in "real" web dev land. Esp WRT NPM/Nuget - that's the big hurdle I think. W:// Sent from my iPhone
|
|
With such an awesomely active community, I can see I made the right choice with Ember! Thanks for the input and its reassuring to know I'm not the only MS shop guy out there doing Ember. Generally C# & .NET is a great back end technology (maybe best thing at Microsoft - so watch them change it). Being full stack, I can really make it sing with Ember/Ember-Data. Of course the MS territory comes with the 'gorilla' argument to smash all rationality, perception, and rigor. You should see some otherwise respectable developers here transform into Bill Gates on the golf course with your CEO when discussing Angular. "Google is biggest, and so Angular will win". (Ah, patronage with all it's pros and cons. What did Google say about not doing evil?). So I'm continually fighting the good fight here. Been experimenting and will report back when I have my new cli setup worked out. |
|
Good to see that there's some interest regarding Ember Cli and Visual Studio! We at Microsoft have been thinking about doing something like this. I don't think that this is about reinventing the wheel, since most tools we need are already there. We already have awesome support for npm, bower, grunt and gulp - so I'm thinking more about bundling the right "configuration" rather then re-implementing work that has already been done. Initially, all I want is to be able to run the Ember cli from Visual Studio, as well as to hook up |
|
I can put a bit of work in but not much. Remember we want to integrate
test too. I've just submitted a fix which gives correct xunit xml out.
So that shouldn't be too hard.
|
|
I would be well up for this. My concerns are that where I work (major finance (read paranoid) co. so not really the norm) they just won't be down with NPM so if there was a way to NuGet it, it might be better but then again what's the point of just having CLI as a Nuget and no access to the rest of the community and resources... If I can help I'd love to. Probably won't be much use outside of testing and maybe a bit of dev because I've got exactly zero experience of doing VS extension type work! But I have a lot of exp with MVC/WebApi/c# etc In sailsjs we have some blueprints that output the JSON in the preferred format (side loading, links etc). Having something like that in WebApi would be very cool. Maybe not enough to blag me back from sails on my project but it would path the way for a lot of people. What sort of integration are we thinking? Sent from my iPhone
|
|
Maybe we need an automated service that turns each cli release into a nuget
package?
|
|
Like I said though, there's no point really having cli as a nuget when every addon needs npm and we can't realistically expect every addon to publish a nuget Sent from my iPhone
|
|
Just to be clear, we (as Microsoft) won't engage in any silly businuess turning any npm packages into nuget packages. From a Microsoft point of view, npm is kinda nice. We integrated it well, there's autocomplete, graphing and a bunch of features supporting it. There are also neat integration features for grunt, gulp and other task runners. If we're doing any work on this as Microsoft, we'll make sure that Ember Cli runs well on Visual Studio the way it's supposed to run. Also, just speaking as a Microsoft engineer - there's no reason to trust nuget more than npm, really ;-) |
|
Totally! And tell me about it, but getting any library (open or closed source) available to the team has to go through a horrific amount of internal testing and vetting. All that aside, what's the order of the day? What would be required to improve the workflow for a standard user with unrestricted access? Sent from my iPhone
|
|
You should realise that the libraries are updated every two weeks, so you'd
better have a lot of people to do the horrific testing, or be good about
writing automated tests.
|
|
Priority 1: I want Since the integration of Grunt & Gulp is awesome and available for some of the older VS versions too, I think that Grunt might be able to help us out here. An ember addon and grunt-exec could make Ember Cli quite accessible to anyone coding in VS. |
|
Are you planning on something built into VS or an addon like the current nodejs support? Got a link to what its going to take to write this? I'm willing to throw in a little bit if its something i understand. There are a great many similarities between ember-cli and features in VS. |
|
If you look where TypeScript is heading in version 1.5 with support for more ES6 feature like modules, let/const, sublime text support, and @wycats influenced decorators, it wouldn't surprise me if TypeScript gets integrated into Ember in the near future. Once that is in place, things will really start to get interesting. |
@felixrieseberg got time to chat about this later this week? I would like to see if i can help move this forward |
|
@stefanpenner: Hangout on Friday? Totally flexible from 10am on. |
|
@felixrieseberg lets do 10am then |
|
I'll find you on Hangouts then ☎️ |
|
I'm very interested in this. I've been working with ember for 6 months, so given my limited experience, how I can help? |
|
Well while a proper plugin is being produced you can use these little hacks to get some tighter integration with visual studio. You can get the debug play button to run ember serve by doing the following.
Then under Server set the following.
If you really wanted to get fancy with it you could create a batch file that also opened your browser. As for getting the rest of the commands to work a simple workaround is to use the TOOLS/External Tools wizard to add menu items for things like "ember test", "ember build", etc... I'm not going to explain exactly how to do it since its almost exactly the same process i described above. EDIT: FYI here are the arguments available for cmd.exe. You can also substitude /K with /C if you wish. http://ss64.com/nt/cmd.html |
|
@Kilowhisky nice! |
|
If you want intellisense, then add an And then in Tools -> Options -> Text Editor -> Javascript -> Intellisense -> Referencesadd the _references file in there. Example: |
|
@felixrieseberg any updates on how to integrate ember-cli with Visual Studio? I have an ember project with WebAPI back-end and it would be nice to integrate CI properly. Thanks! |
|
We would also like integrate ember-cli with VS2015 so following this with interest... Thanks. |
|
There is some work going on in #4576 that will help with this effort. |
|
+1 here. We are now migrating from ember 1.9.0 to the current version and it is so frustrating that they changed from a "Javascript Framework" to a "node based Javascript Framework". It is kind of a big project we have built on Ember and WebApi and it's very hard to get this together with all the changes they made. |
|
@PhilippRoessner just so you know, we made sure ember continues to work without ember-cli. For exactly this usecase, and will continue to make sure it does. CLI is merely an opt-in, it is worth noting, that using cli does reduce the friction of using ember addons. |
|
@stefanpenner yeah, it is possible, but not as easy as it was in the past. Especially to follow the guide on emberjs.com and getting started. We used a few ember plugins like Addepar Ember, They don't work anymore and I want to switch to an ember addon. I have no Idea how to do that. Implementing template precompilation was a big change for our Dev Environment. Now we need Node.js, Grunt and so on. So, not using ember-cli makes this more complicated or you have to face many disadvantages like, pre-compiling on client. I think the biggest problem with "Not using ember-cli" is that all the automatic build magic it does, is hard to understand for someone who has no clue about node.js. And in the past, it wasn't even necessary. |
|
So what your saying is. Ember-cli saves you time, and solves existing problems so you don't have to? Of course with some trade offs, but what you describe appears net positive. Obviously the cost of the features is transitioning of a more legacy setup. In the past you where still compiling templates on your clients. Which was likely causing perf grief. We do plan vs integration I hope that will aide you when it lands. |
|
What I describe is that updating to newer versions of ember, to have the benefits of the new Version, requires you to change completely the development ecosystem when u r working with Visual Studio. It is not even possible to get a EmberApp into the TFS when it was created with ember-cli see this node-based problem Don't get me wrong, ember-cli is a great tool when working with ember. But getting both together, "ember without ember-cli" and Visual Studio, is complicated, "ember with ember-cli" with Visual Studio is not possible. |
|
But nothing is stopping you from using ember without ember-cli. Except the new things ember-cli adds, like a rich addon ecosystem. Re: the issue you linked, npm v3 can help a lot. And ember-cli itself has been made to work correctly with v3.(I have been working with npm folk close to ensure this to be the case) I am actually aware of quite afew people who use ember-cli on windows and even with vs, the only issues they have (after follows the instructions) is slower build times then there posix counterparts. In-fact our CI also runs on windows to confirm the system works. The integration we speak of here. Is really, improved getting started experience and tooling integration. |
|
Re Addepar, take a look at shaunc/ember-grid that Shaun and I have been I use ember-cli on windows and in a windows CI system and don't see any Bryan Crotaz On 1 Sep 2015, at 15:16, PhilippRoessner notifications@github.com wrote: @stefanpenner https://github.com/stefanpenner yeah, it is possible, but We used a few ember plugins like Addepar Ember So, not using ember-cli makes this more complicated or you have to face — |
@BryanCrotaz awesome! Is this using ember-collection under the hood? |
|
@CuriousCain i suspect we can actually produce a pretty great references.js file automatically, is there a way to have VS pick it up automatically? |
|
@PhilippRoessner: Just a quick FYI, Visual Studio and Ember Cli totally work together. We're using it at Microsoft for a bunch of projects. |
|
@stefanpenner It looks like, now, by default VS2015 automatically creates a No special settings need to be altered (like in my previous post) |
|
@felixrieseberg Is there any documentation on how ? :-) |
|
In short: Use the nodejstools, npm@3, ember-cli-windows, PowerShell as Administrator, and you'll have a good time. |
|
@felixrieseberg Ok, Thanks 😄 |
|
Had a hell of a time getting ember-cli and visual studio to play together.
You’ll need to first get https://www.visualstudio.com/features/node-js-vs from nugget installed and make sure this is checked:
Then create a new project, I chose MVC5 web api. After this in elevated powershell navigate into the solution folder and run which will make a new ember app named "fire":
Get a coffee or a beer or both... Next right click the solution > add existing website > choose fire folder Back in powershell run:
Pat yourself on the back and don’t tell M$, they don’t know this yet. If you tell M$ they may not have any reason to fix an ongoing file name length issue but likely won't matter as it seems they have zero interest. Am using the very latest versions of everything.
If you made it this far take the rest of the day off!! |
|
@areaintel sounds like a good potential contribution to the website, so future travelers also find this. cc @felixrieseberg any thoughts? |
|
+1, we should probably have a guide. I'll put it on top of the todo list ;-) |
|
For me, I mark the |
|
A proper how-to would certainly help. I found it easy enough to get a project started and load the code into VS for editing; it's the integration with ember-cli for things like Build, Run, etc. that's elusive. In the interests of disclosure, I'm not a VS power user so I'm likely missing something very obvious for setting up the above. :P At any rate, I'm bookmarking this thread in case some folks drop any further details (or to do so myself if I manage to figure it out at a later date). The bigger priority at present is actually using Ember to make a cool thing. ;) |
|
Any updates on this @felixrieseberg ? One link you posted is dead, the other links to a 3 year old repository. What about that guide that was on top of the Todo list? |
and others
I am happily using Ember inside of Visual Studio with the help of Gulp and Task Runner Explorer. I'm in VS because my back end is C#/.NET. Also, I'm using TFS rather than Git, but that is another story.
See: https://visualstudiogallery.msdn.microsoft.com/8e1b4368-4afb-467a-bc13-9650572db708
It is unclear how I should migrate to Ember-cli while maintaining an equivalent productive experience in Visual Studio. Is there anyone out there who has solved this issue?
Looks like I can stay with Gulp for the time being - a HTMLBars Gulp plugin is available. However, I'm concerned that I'll be stranded if I don't switch to Ember-cli eventually.
The text was updated successfully, but these errors were encountered: